What is our primary use case?
For engineering in the oil and gas industry, most of these companies, specifically in the Texas region, are kind of OpenText customers.
Since we all do bigger enterprises and stuff like that, I go to these meetings called Regional User Groups, which are oil and gas-based quarterly meetings to discuss and look into the roadmap, look into the products, and stuff like that.
So, I know pretty much almost every single company here is an OpenText shop inside this oil and gas industry. OpenText Extended ECM for Engineering is a big product that most of these companies have in common.
OpenText has different product stacks. One of the products, which was primarily called Content Server or Content Suite, has been rebranded as Extended ECM, essentially Extended ECM platform. So OpenText becomes ANY basic ECM.
It’s a bigger module suite. It’s another application altogether to manage engineering drawings and the lifecycle of engineering-related stuff. So that’s another stack.
Now, consider that if you come to SAP, they call it Extended ECM for SAP. The terminology is still the same. The common term is Extended ECM; then the extensions are called something. So if it is engineering or operations-related stuff, dealing with drawings and other stuff, we call it Extended ECM for engineering. If we are dealing with SAP-related information or asset information, we call it Extended ECM for SAP.
So Extended ECM for SAP comes in two different kinds of flavors, if you will. There is a smaller flavor, and then there is a full-blown capability related to stuff, which is called Extended ECM for SAP. Extended ECM for SAP typically starts with a small implementation. However, most manufacturing companies have a SAP footprint, and if they are getting started either in OpenText or stuff like that, they will integrate at some point for the attachment parts of the SAP implementation because SAP HANA is a costly deal. You don’t want to architect all the content, which is not essentially business content, to store in an SAP HANA database. So that’s where Extended ECM for SAP comes into the picture.
Most of the companies I had some past experience with this bigger manufacturing company will integrate their SAP, not completely with OpenText, but using a smaller integration. It’s called archival and document access (ADA). That’s the component most of these companies will utilize. At a certain point in their implementation, they’ll realize, "Hey, let’s take a closer look at the full-blown capability of Extended ECM for SAP." So that’s where this kind of rollout will evolve.
How has it helped my organization?
Consider you have some use cases. For example, something for your accounting or procurement department. And you purchase equipment, machines, and plants for plant-related operations. Essentially, there will be manuals and basically anything and everything related to your particular equipment. So, where do the equipment entries go? They go into SAP. Depending on your SAP deployment, it can go into some database. Most companies these days are talking about SAP HANA and stuff like that. So it will be stored in SAP HANA.
But, these documentation, drawings, manuals, and help files for these big pieces of equipment, where do they go? That’s where Extended ECM for SAP comes into the picture. All these integrations are through a one-way push, essentially, but with two-way access. So as a user in the procurement department or the accounting department, or an engineering department where you are using SAP for asset management entries inside your system. All those related documents, drawings, manuals, and files have to be stored somewhere.
If you store them in SAP, it will be a costly implementation going forward. After maybe a couple of years, you will realize that it’s too much to deal with because HANA database will be too costly. There will not be much business value because you cannot utilize a lot of search and cool features inside your application from an SAP perspective. That’s where you will integrate SAP. For example, SAP Extended ECM for SAP Plant Maintenance. One of the modules SAP provides is SAP Plant Maintenance.
So what you will do is deploy Extended ECM for SAP, then try something called SAP Plant Maintenance, Extended ECM for SAP Plant Maintenance. The content maintenance, manuals, files, drawings, and related stuff, its details or tags, or any kind of stuff is stored in your SAP. But anything and everything else is pushed through this integration into Extended ECM platform. So now it is available to be utilized by your business user who knows nothing about SAP.
They only live and breathe in a different management system. They can look into these details depending on what kind of integration has been done for that company. So that’s one use case.
Second use case will be in SAP itself. Now, if you are an SAP user, you have this information readily available at your fingertips. Anything goes wrong in your maintenance or any kind of management, you can look into these details, which are readily available because this documentation lifecycle is being managed by Extended ECM for SAP. It will give you extended storage capabilities within your SAP application. So it will be a two-way integration, essentially. Similar, wider features will be available within Extended ECM platform.
Within SAP, you have these extra features called business attachments or business content retrieval. Those business contents are stored inside Extended ECM, and those features will be available within your SAP GUI from an SAP perspective. So it’s a win-win situation for both worlds.
What needs improvement?
Improvement could be more about training because it is one of the giants in this market. Nobody can be exposed to SAP and other stuff. So the deployment could be costly because of resource availability.
If SAP could come up with more user-centric information for management and integrations, making it as much as possible out of the box, that is something which I think could or should be improved.
For how long have I used the solution?
I have been using it for close to eight years.
What do I think about the stability of the solution?
It’s very stable. In our case, we deployed something called ECM ArchiveLink, which is a component of the Extended ECM SAP framework for SAP integration with something called Archive Content inside our application. Archive Center is another component which we utilize to store actual data, which basically stocks to our physical disk to store the content. It’s a very stable solution in my opinion. It has hardly failed us in the last eight years.
What do I think about the scalability of the solution?
Scalability-wise, it’s available for any and every kind of use case. It really depends on which business area you want to integrate with your deployment. They have something called solution accelerators.
There are solution accelerators, which are out-of-the-box standard solutions for this kind of integration and best practices for your specific business integration aspect. You can scale the solution to any business area depending on the solution accelerator. Taking help from the solution accelerator can help deploy a scalable solution for the SAP world.
How are customer service and support?
I have my team who handles SAP and stuff. They will have support specifically for SAP.
If you go to SAP, they will create a ticket and give you a reference. If you’re a customer through SAP, their responsibility will be more of first-level support. These nuances come into play when talking about technical support.
How would you rate customer service and support?
Which solution did I use previously and why did I switch?
We definitely utilized something called extended ECM for engineering. It’s big, and it has a bigger market in the oil and gas industry. So extended ECM for engineering, then extended ECM for SSE, then extended ECM in general for the document management part, the search part, and stuff like that.
On the back end side, we are a Windows shop, so Windows in WAP. On the database side, Fintech does not necessarily have dependency on a particular database. But in our case, we do utilize Microsoft SQL as our database engine for the application side of database stuff like that.
So that’s the high-level kind of stuff we utilize. We also utilize Atlassian Jira and things like that for service management aspects and stuff like that.
How was the initial setup?
If it is just a small, easy integration of SAP for some specific business cases, it could be simple enough, and it could be really complex because you have to involve both business partners from a customer perspective.
Both the business owners and then the content owners, who are those who live and breathe in SAP. It’s not just about the technology. It’s more about the people who will be utilizing the product and the actual content.
So, those will be the areas where complexities typically come. If we go through this kind of rollout and integration, it’s a complex process because you are talking about two different worlds working together as seamlessly as possible. But it’s not about technology. I think it’s more about the content. It could be complex because there is less out-of-the-box support available from these two companies in my experience. So that could be a bit tedious to achieve.
What about the implementation team?
What was our ROI?
We have not been using the complete extended ECM from SAP, but we have been utilizing this half-baked solution called ArchiveLink for SAP. And that’s a lower-level integration available from SAP world. We have been utilizing that for the last eight years. So, the ROI is in terms of the database cost. If you are going to store 50Gb worth of data inside your HANA database, it will be super costly for sure. That’s why these kinds of integrations come into the picture: to save some costs around there. If you try to store everything in the HANA database, it will bring up the support performance of your SAP system and the cost of your implementation on the high side because HANA is not cheaper.
So, if HANA is not cheaper, and we utilize this integration, from a deployment perspective, it all comes down to just a license cost. Once you purchase it, you have paid the license upfront. Once you have done the deployment, all this content will go into our Archive Center, which is another component. And that’s going onto your disk. So, it all comes down to your disk pricing. Any kind of disk storage or any kind of vendors around these kinds of storage pricing will always be cheaper than the SAP HANA database pricing. So that’s where I think we save a lot of money.
What other advice do I have?
I would rate it maybe eight out of ten because I’ve seen the stability. It’s amazingly stable. We have not completely rolled it out the way I would like to, but we are looking into that. Most likely, in a couple of years, we should have a full-blown integration done within our company. So maybe after a year or two, I’ll be in a better position to tell you more stories around it.
*Disclosure: My company does not have a business relationship with this vendor other than being a customer.