I am having another question where I would like to use your experience/guidelines.
I am now in preparation of a "queen of projects" where we will migrate our current ERP application to a new Application
Current landscape:
a) FICO is hosted in SAP 6.0
b) other processes like MM, Contracts, Invoicing, Order mgmt, other specific functionalities are hosted inhouse-built application
Reason to leave inhouse-built application: the app started ~25 ago and it is written in language, which is not supported by many developers nowadays, which usually delays enhancements/new projects
Do you think it is appropriate to delegate new application selection process to specialized consultancy company, which could see the list of our company processes and assess which other app makes best fit
As of now we mention as potential targets S4Hana, Oracle, Dynamics but might be as well any other - if good enough
Or would you rather recommend to run selection process of a new application on "my" own without involving "agent" company Saving Changes...
I was in charge of the whole migration project to SAP for the company where I am working today. And from that, to the next versions. Key points are requirements. To use or not to use an external consulting service does not matter.
SAP is one the main contender in our selection process as we have already FiCo module in, and our Mother-company in US as well recommends SAP - as they consider it less implementation risky as they have it themselves as well (they know it compared to other apps which are unknown)
How long took your SAP implementation process?
My company as of now like to have very safe module by module migration ~3 years, however, as I talked with SAP implementation vendors they usually prefer ~1 year big-bang approach as overall effort is lower and it is as well not good to spread project too long / built new interfaces in transition period Saving Changes...
Lukasz, this is not primarily an IT project.
Best is you have a business sponsor.
Thomas,
now you touched the Hottest part of the "my" Project, as every Project has its Specific - that is the No 1. Specific of this one.
as of now there is no Business support for the project
- Business have their own pure Business related objectives
- They got used to the current app (although it is quite old)
- In the current app is is home-made many user-wishes in slow-speed but were implemented
- we failed SAP migration project ~10 years ago and people remember it
So it is as of now IT team to:
- build awareness & educate Business Leading team
- prepare step by step for the change
And I am still not sure who could be Business Owner for ERP migration project but you are right - usually the Project should be driven by Business Owner and "only" executed by IT (not our case yet)
So currently we formulated that as official/primary corporate goal for 2022 on the level of Executive Team, so the question would be now how in organic / correct way translate it so that some senior manager from Business would take over the Business Owner role with natural Buy-In. Saving Changes...
Financials, Materials Management, Order Management, and Invoicing are generally handled well by the big players you mentioned (i.e., SAP, Oracle, Microsoft) due to their adaptive configuration capabilities, and the cross-industry compatibility of these modules.
However, Contract Management is usually a different beast, and when coupled with Leasing, becomes a black hole of complexity. For instance, is your leasing division a captive entity that funds your division? Do you have third-party leasing requirements, what are the regulatory concerns, etc. Does your system need to handle automated buyouts, refinancing, trade-in’s, competitive churns, etc. The list, which I’m sure you are aware of, goes on and on.
The big players have traditionally struggled with contract modules, and they may have reservations if you genuinely need a full-blown end-to-end leasing system. Although they may try to draft you into a custom development arrangement wherein they develop/customize a module for your market.
Bottom Line: You need an experienced enterprise architect who can “truly” navigate the business and IT domains of your extended enterprise and work with you to “challenge out” the requirements and package(s) selection. This can obviously be done through a specialized consulting firm, but even then, I would recommend having your own EA to challenge that.
George
George,
i take 2 points from your side
a) did not consider Contract module so far as the one, which might be more problematic compared to others
b) good to have strong architect internally (I have 1 person in mind but will make internal consideration about it)
regarding contract module:
our specific is that company A may lease the product to company B who lease it to customer - so we have inter-company transactions
others:
a) we are leasing our product for yearly contracts
b) we do so acc. to general terms & conditions (couple of versions)
c) contract may include costomer specific requirements incl discounts
d) as of now we do have "captive" divisions but rather all entities work equal
e) based on contract - rental invoices are produced
f) we do not use: automated buyouts, refinancing, trade-in’s, competitive churns Saving Changes...
Dear Lukasz
The processes you mentioned are crucial in the ERP, mainly because of the interrelation and interfaces between the FICO processes with contracting-supply chain -MM in terms of governance system, inputs, and outputs. So, when it implements the new software, the final users and key stakeholders involved in the governance system shall work with new processes. Those changes will bring a lot of uncertainty throughout all processes for everyone. Indeed, if the risk evaluation and stakeholders’ management are not appropriate, the operation will be impacted. So, I recommend using a consultancy company with experience in SAP and those processes to migrate to maximize your investment and time. With this, the organization can minimize the impact during the migration, designing a transition plan for preventing loss of time and rejection of users and stakeholders.
Besides, it should create an internal group formed by experts, final users and key stakeholders to work in collaboration with the consultant for searching a way of work that reduce the impact of failure during the migration and ensure the scalability of the product.
Elena,
yes, as of now we at the beginning of our journey with one consultancy company from Germany who will advise us on potential COTS which could be best fit for us
we did not decide yet about how to do change management, which is more for the future Saving Changes...
Referring to Elena's points: I have good experience with an external consulting company, too, especially when it came to challenging statutory requirements: EMEA vs. the U.S., and Russia, and the Middle East (consultants' comprehensive experience and knowledge). In addition, it was an integrated project delivery: project management + change management (a consulting firm + internal SMEs and process owners covering all functions of the value chain). But, of course, there are some pitfalls of working with consulting firms, e.g., optimistic project planning, etc.
Maria,
yeah, I like it that external consultancy can give us good input, but personally I am sceptic, quite balanced as it is still on 'us' to trust external company did good work and we can transfer that to our organization. I will always question & try validate it to the level possible. Saving Changes...
If your applications were written based on the work flow 25 years ago, the software and processes probably evolved together over time without thought to digitally integrating data sources later.
One reason is that newer systems will likely have data more structured so the information can be found in the right place and with a consistent format. Older systems tend to use more free-form data entry and the same type of information could exist in multiple possible location and formats.
Trying to merge new COTS systems with old homegrown systems may become difficult. Data migration may require some reformatting so the conversion scripts can find the right data in the right place. In a text field, Part Number 123, P/N 123, Part # 123, and just the 123 all mean the same but may cause data conversion issues. There will likely be process changes required as well.
Unless you have very knowledgeable people in the before, after, and how to transition you are likely to encounter many surprises and you may lose significant functionality advertised by the software vendors.
Keith,
I am not sure if I understood the last part. What would be the background reason to potentially lose significant functionality or have surpises? I mean still due to data migration issues..?
...
1 reply by Keith Novak
Dec 02, 2021 12:27 PM
Keith Novak
...
Lukasz,
It is not merely the data migration itself, but the total cost and disruption to migrate the data, and then change and validate processes originally designed around a customized tool, so that you can perform the same/similar functions in the new tool and still meet all your business requirements.
Brownfield and greenfield projects have their tradeoffs. Customized tools may be very efficient for your custom needs but difficult to integrate with other tools. Large highly integrated tools may be costly to customize for your own unique business needs so the processes are dictated by the tools.
With enterprise level systems, data goes many places most people had never even considered; not only different parts of the enterprise but also to external customers, vendors, regulators, etc. who may have all adapted their own processes and tools to the old systems. The total cost and disruption involved may outweigh using the new functionality and instead you may retain some legacy systems for your own needs. The functions look great in the sales brochures, but it turns out the cost and effort to transition kills the business case to use them.
A simple example is a new data management system implemented by my employer that works more like navigating web pages than reading a single document. We sent product data to a customer in a less developed nation and it turned out most employees worked off printouts rather than having PCs. The office manager would need to take hundreds of screenshots to print for their own employees. It did not go over well and significant additional effort was required to provide printing capability which eroded our expected cost savings from the new system.
Understanding whether new functionality may be used as intended, or major work is required to adapt the software or your processes to the software can dictate how much of the new tool suite you actually implement and the resulting ROI.
I am not sure if I understood the last part. What would be the background reason to potentially lose significant functionality or have surpises? I mean still due to data migration issues..?
Lukasz,
It is not merely the data migration itself, but the total cost and disruption to migrate the data, and then change and validate processes originally designed around a customized tool, so that you can perform the same/similar functions in the new tool and still meet all your business requirements.
Brownfield and greenfield projects have their tradeoffs. Customized tools may be very efficient for your custom needs but difficult to integrate with other tools. Large highly integrated tools may be costly to customize for your own unique business needs so the processes are dictated by the tools.
With enterprise level systems, data goes many places most people had never even considered; not only different parts of the enterprise but also to external customers, vendors, regulators, etc. who may have all adapted their own processes and tools to the old systems. The total cost and disruption involved may outweigh using the new functionality and instead you may retain some legacy systems for your own needs. The functions look great in the sales brochures, but it turns out the cost and effort to transition kills the business case to use them.
A simple example is a new data management system implemented by my employer that works more like navigating web pages than reading a single document. We sent product data to a customer in a less developed nation and it turned out most employees worked off printouts rather than having PCs. The office manager would need to take hundreds of screenshots to print for their own employees. It did not go over well and significant additional effort was required to provide printing capability which eroded our expected cost savings from the new system.
Understanding whether new functionality may be used as intended, or major work is required to adapt the software or your processes to the software can dictate how much of the new tool suite you actually implement and the resulting ROI.
Keith Saving Changes...
Luis Rincones HigueraData Migration Analyst| PersonalJacksonville, Fl, United States
Hi Lukasz
The content in the above answers is all very useful, and you should consider adding it to your pre project documentation.
I like to emphasize a few items.
• Budget
o Costs overrun are a hard reality in ERP Implementation
• Data Migration.
o How is the legacy data organized?
o Is the Metadata updated
• How much is the organization willing to adapt to standard process?
• How much time do the Process and Data SMEs, can invest in the project?
• The legacy maintenance team are a valuable resource that could be of help in the selection process and in implementing the solution.
I would definitely recommend using specialized consultancy company to help you select assess and select the right product for your need. This is a huge decision and can have significant implication if you do not select the proper product for your company. A good System Integrator will bring valuable knowledge on the existing products and will be able to help you select the right one for your company. There are several good options out there however, without the knowledge of your needs and your organization it is hard to recommend a specific product.
In addition to SAP and the other products you've mentioned, there are good products like Infor and Workday. I personally completed 2 full implementations of Workday (Finance and HR including payroll) and was very impressed by the product and I'm currently implementing Infor (Finance & Supply-chain), both are SaaS products with very good integration platform so integrating them with your on-prem applications/systems should not be too difficult to achieve. Saving Changes...
Milena IlievaProgram Manager Global accounts| VMWareVienna, Austria
Lukasz,
I am currently managing a program for implementing one ERP system in 6 countries. They all have currently different systems, and one of them even running SAP.
Our FICO is on SAP and preferences from Corporate are for SAP (S4HANA actually), but business specifics, customisations (local specifics require that specifics are possible in the future system), support and maintenance (in the future) make us look around for other solutions.
I fully agree with Thomas that impementing ERP is not an IT project, but rather business project. Therefore you need ownership and commitment from the management top down in the company for the new system implemention.
Whether you go with an external consultancy company for choosing the right solution or not, it still requires commitment and own resources to work with them.
This came up during our preparation and having short demos with different vendors - vendors and consultanting companies always come with estimation and costs for their work considering their time. Their assumption is that the resources on your side are available.
One other point I would like to comment on - change management has to start from the very begining. Start with building awareness and commitment from management and have a supportive and committed sponsor from the very begining. Implementing a new business system requires change in mindset in different levels and departments. And the work for this (how, who, ..?) has to start from the begining.
