Well, Helm cannot deploy itself. It only provides primitives for Helm Charts, which you can install when your infrastructure is set up accordingly. In order to deploy anything you need some sort of pipeline that puts all the pieces together.

OLM is a declarative approach to solve some kind of release management where you define different versions of "deployables" which are then upgraded. I have yet to understand how this can be used with custom services. As far as I was digging some time ago you could only use some predefined applications. Also note that OML does not replace Helm. I would assume whatever "deployable" OML manages, can also be something that is installed via Helm at the end of the day.

Helm provides the ability to install applications onto Kubernetes via Helm Charts, which themselves are a collection of templatized K8s manifests. It handles only the basic lifecycle of these applications (install/delete/rollback/upgrade) by rendering these templates and feeding them to the K8s API server. Based on the version of Helm, there are limitations related to dependency management and which resources can be created in which namespaces.

OLM (Operator Lifecyle Manager), as the previous user mentioned, is a declarative based system which is meant to support installation of Operators, which themselves are responsible for providing the logic and instructions to manage the lifecycle of an application (install/create/delete/upgrade). OLM is an opinionated approach to managing the lifecyle and packaging of these Operators. There is also an SDK which help users create Operators from Helm/Ansible/Go to fit into this system. It has various components which talk to each other through the K8s APIServer heavily leverages CRDs and CRs resources to make this all happen.

Benefits/differences:

Both can be used to install/delete/rollback/upgrade an Operator, but OLM offers a model whereby you can craft various methods of deployment operations for your application deployment (think alpha vs stable) into different subscribable "channels". As you update these the methods in these "channels", those that are subscribed automatically gain the ability to upgrade/install a newer version according to these methods. Dependencies in OLM are also handled in a different way, and you can have a chain of dependent Operators installed, in order, in various namespaces. Helm is a bit more restricted in this regard.

Lastly OLM make the assumption that your container images are publicly reachable and their use in manifests are built into containers (CatalogSource, Operators, etc), whereas Helm charts much more easily modifiable using various Helm based CLI commands (or 3rd party tools) to override template values before creation.