There are many challenges that managers face when implementing an enterprise level software package. But of the following, what would you consider the biggest challenge?
1. Data Migration
2. User buy-in and resistance change
3. Gathering proper requirements
4. Developing accurate business test cases
5. Poor data quality
6. Limiting access to immediate results
Let me know what you think...
Subscribe to:
Post Comments (Atom)
Content Subscription
Posts
Comments
In my expeerience, out of your list, the two big challenges are "Gathering proper requirements" and "user buy in and resistence to change" in that order.
ReplyDeleteFirstly, the need to gather proper requirements for an enterprise wide implementation, taking care of the integration with internal and extternal entities is a huge task and need to be done accurately to implement a proper enterprise solution.
Secondly, the resistence to change is a big factor. It is understandable that you need to move carefully when you want to re-implement part of whole of enterprise application. However, resistence due to political and technical (more political, I guess) reasons, slows down or inhibits the change.
The other challenges that you have mentioned, ex: Data migration, could be a huge effort, but is not a deterrent.
LinkedIn Groups
ReplyDelete* Group: Data Warehouse & Business Intelligence Architects
I think that I'm tired of trying to solve problems in boxes (or pigeonholes or silos). Virtually every problem that we are trying to solve today is part of a web, contained within a matrix. They are all related and if we would spend our time and energies on the matrix (not The Matrix), many or most of the day-to-day problems would solve themselves.
We sneer at the business side for doing foolish things caused by the left hand not knowing what the right is doing and yet that is exactly how we spend our time. That's what I think.
Posted by Mike Meier
LinkedIn Groups
ReplyDelete* Group: Microsoft Business Intelligence
I think either of the points you had listed could be the most challenging for any given project. I would imagine that the typical, greatest challenge is data migration and gathering proper requirements.
Posted by Paul Hamilton
LinkedIn Groups
ReplyDelete* Group: Business Intelligence Professionals
It often is the human (non technical side of things). Anything from expectations, budget, time line and in-exeperience in deploying analytical systems.
Posted by Jamison Chochrek
LinkedIn Groups
ReplyDelete* Group: Business Intelligence Professionals
Common agreement on who to use to do the work, data management storage and technologies, security, heterogenous technologies merged together from acquisitions or different autonomous departments, lack of budget, poor relationship with outsider vendors, mis-informed expectations, lack of vision, no roadmap strategy (1/3/5 years out), biases and personal sentiment, mis-informed or ignorant leadership, poor project management, and horrific communication between vendors, departments, and management.
That's more than one reason....but those are just a few I have seen in my experiences.
Posted by Greg Williams
LinkedIn Groups
ReplyDelete* Group: Microsoft Business Intelligence
Obviously a lot would depend on the organization involved and how well the software solutions fit the business needs. Of the list you provided, I have rearranged them in the order that I have experienced in the past from most to least challenging:
1. User buy-in and resistance change
2. Gathering proper requirements
3. Poor data quality
4. Developing accurate business test cases
5. Data Migration
6. Limiting access to immediate results
Posted by Sandra Humphreys
LinkedIn Groups
ReplyDelete* Group: CIO Forum
I agree with Ananth, and add the following:
1. You need to have all your business processes defined and a Gap analysis between processes defined in the system vs. what is on the ground.
2. Avoid any customization to the max as this may backfire when there are new releases and upgrades.
3. You also need to have Management's buy in for making necessary changes (Change Management) which may mean changing the way business is done, and / or making necessary staff adjustments (hiring - firing, reallocation ...) .
Regards
Bassem
Posted by Bassem El-Wazir
LinkedIn Groups
ReplyDelete* Group: Microsoft Business Intelligence
I'll second Sandra's list and add the general observation of "The business can't handle the paradigm shift". If you do not quickly address or dispell "...but we can't do that because..." you may rest assured the project is on the road to failure.
Posted by Garth Honhart
LinkedIn Groups
ReplyDelete* Group: CIO Forum
Of course you must do the things that Ananth and Bassem describe. I am a huge proponent of a change managment book I devoured last year. Take it one small success at a time. Phase and sub-phase if you can. It works. As for number 3 in Bassems comment, the human factor cannot be taken lightly and I would submit needs to be high on the priority list. Only takes one saboteur.
Posted by Hope Mentore-Smith
LinkedIn Groups
ReplyDelete* Group: CIO Forum
Those are all common problems, but the best way to "mitigate" those problems is to use Agile methodology for development and deployment. We use it with amazing success and provide demonstrable results for our clients.
We typically do two week "sprints" throughout the life of the project. Clients get deliverables at the end of each sprint. This way, you can make and incorporate changes rapidly, and not stall the ultimate delivery date.
We have been so successful with Agile that many of our clients have asked us to train their internal teams on the methodology.
John
Posted by John Loughran
LinkedIn Groups
ReplyDelete* Group: SDForum
Hi Matt,
I am a Sr. Technical Recruiter and sometimes we work with very small companies (5 -10 people) and they look for Enterprise wide developers and want to pay $40/hr. What are companies thinking these days?
Bridgette
Posted by bridgette marks
LinkedIn Groups
ReplyDelete* Group: CIO Forum
Actually, an Agile methodology is probably one of the worst things to use for large scale enterprise software implementations. An enterprise deployment must be well thought out, designed, and planned. All of the contingencies, integration points, and business process changes need to be identified upfront. By design, Agile methodologies have a short deliverable horizon and do not allow you to see the big picture during a Sprint or an Iteration. With large initiatives that require identification of many factors upfront, Agile methodologies start to fail. They are based on the idea that small deliverables will allow business stakeholders to see results faster and future changes can be easily accomplished. With enterprise software implementations, it is largely all or nothing situation. If you fail to recognize certain risks, integration points, requirements, or platform configuration parameters, the cost of change becomes too high. Also, business users only care about the final product, not the series of small deliverables to reach it. Thus, I would recommend using Waterfall or Iterative methodologies for enterprise software implementations.
Posted by Leo Shuster
LinkedIn Groups
ReplyDelete* Group: CIO Forum
Regardless of the methodology you use, regardless of the rigor of requirements gathering, project management, etc.....you have to have buy in from the business. Enterprise implementations are (properly) done for business reasons, not technology reasons. If you're implementing because of technology reasons, it only takes a shift in a surprisingly small number of opinions to turn the project into a target, and any support you have will evaporate quickly.
If you focus on the business need, and continue to engage the support of senior management, you'll fare much better.
Posted by David Hollingsworth
LinkedIn Groups
ReplyDelete* Group: Business Intelligence Professionals
Management buy-in and support; posted, stated and tatooed rules and responsibilities; clearly defined expectations, goals and dates; and absolutely it's all about the data - junk in equals junk out.
Posted by Beth Carpenter
LinkedIn Groups
ReplyDelete* Group: SDForum
Can the implementation plan be managed smartly so you win all? Implementations is of software needs all of planning and very good contract.
Tamer-Libya
Posted by Abdulaziz Tamer
As per my experience the biggest challenge is "gathering proper requirements". Rather the proper phrase would be "Translating gathered requirments into proper system specifications". The biggest challenge is to translate the requirements of the business into effective business case and system specifications that would make the implementation of the Enterprise solution survive for many years rather than just couple of years. Any Enterprise Software implementation shall be termed as successful implementation if the software is used and is efficient for atleast 5 years. Anything less than that will not have any ROI and would be a waste of time and money
ReplyDeleteLinkedIn Groups
ReplyDelete* Group: SDForum
The greatest challenge in enterprise software implementations is communication.
Mainly between marketing and IT. Next goes coordination and synergy. But last two are rarely acheived in business. Mainly in sport. We will have more clear picture if we will look on business as on sport in terms of communication, coordination, time on taking decisions and motivation of players.
Dmitry Amarandos
www.shmugle.ru
Posted by Dmitry Amarandos
LinkedIn Groups
ReplyDelete* Group: SDForum
Project manager... communication, clear vision of what, when and who is doing it. Understand "who" strength + weakness, affects "when". The bigger the organization other resources are "borrowed", can impact time-lines.
Posted by George Frankel
From my experience, David Hollingsworth comes the closest. As technologist, it seems obvious to us that all requirements are important, cool technology features are important, long projects with steady paychecks are important. In reality, it's the business that's important. If a new initiative doesn't create value for the organization, then it's not a good use of capital. And when I say value, I'm talking about bottom-line, measurable, dollars and cents. By the way, you can't understand the value a technological project will have unless you understand the business model and the strategy of the business. Strangely enough, it is not unusual for me to encounter business owners that understand neither and this spells a roll of the dice for any initiative.
ReplyDeleteAs service providers, it's not about us. It's about our client. Providing true long-term value is the key to success in this flat world in which we live.
LinkedIn Groups
ReplyDelete* Group: SDForum
I have been involved in dozens of implementations of ERP solutions over the years. Project planning and overall project management can be challenging tasks since enterprise implementations usually impact on every facet of the business. Another common challenge would be 'scope creep' which may or may not result from inadequate discovery of requirements.
Posted By Alex Ciacci
LinkedIn Groups
ReplyDelete* Group: Supply Chain Today: Continuous Improvement, Technology
Hello Mathew,
You have correctly high lighted some of the deterrents for adoption of Enterprise Software.
Considering the limitations reflected, the low implementation and training with comprehensive functionality delivered on highly user friendly interface can enhance the adoption of any enterprise solution.
You may like to look at how VENDX (www.vend-x.com), is designed to deliver the value in all above aspects in the transaction process for arriving at Buying decisions.
Posted By Suhrid Shah
LinkedIn Groups
ReplyDelete* Group: Supply Chain Today: Continuous Improvement, Technology
After losing years of my life implementing several SAP, QAD and Oracle implementations I noticed a couple problems. Data integrity is a major issue, which you mentioned. Also, I find companies become too reliant on tools like software thinking it is the panacea for their problems. ERP demos are great. However, it is the subtleties of processes and the multitude of organizational silos that can become instantiated by a software implementation. So breaking the walls down is equally as important in an enterprise-wide ERP implementation. Once the processes are defined the other problem to address is getting the software to accomodate the new processes. In many cases, processes have to be changed to accomodate the software. So it takes creativity and accomodation to implement an ERP solution and make it work.
Posted By Ben Lowe
LinkedIn Groups
ReplyDelete* Group: Supply Chain Today: Continuous Improvement, Technology Innovation, Executive Jobs, Education 10,000+
Some great discussion points here for those rolling out enterprise applications.
Thanks,
Dave Waters
Supply Chain Today
Posted by Dave Waters
LinkedIn Groups
ReplyDelete* Group: Business Architecture Community
1. Data Migration - is only a problem if you have poor data quality. That means you have a poor data architecture. Starting with semantics and ownership, clean up the data and migration should be pretty straight forward.
2. User buy-in and resistance change - This is your biggest problem;all other problems aside. You can have perfect requirements, a brilliant development team, spot-on testing, and on-time/within-budget delivery. But if you don't follow up delivery with formal Organizational Change Management (OCM) then all you've provided is a deliverable, not value. Formal OCM gets everybody on board, quantifies and manages the impact across the enterprise, mitigates resistance by incentivizing change, and puts in place a support structure for those struggling with change.
3. Gathering proper requirements - classic problem; see CMMi, ITIL, RUP, etc.
4. Developing accurate business test cases - another classic problem. It's only magnified by an enterprise software implementation.
5. Poor data quality - see #1
6. Limiting access to immediate results - means too much focus on implementation and not enough focus on the business problem the enterprise software was meant to address.
Just my 2 cents.
Posted by Geoffrey Balmes
LinkedIn Groups
ReplyDelete* Group: CIO Forum
1) Capturing all requirements and categorizing them into - Must Haves and Nice To Haves. Mostly the Nice To Haves stretch the entire application development cycle and lead to disinterest and frustration from users as well as developers.
2) Choosing the right technology and methodology
3) Overcoming the resistance to change amongst the target users
Posted by Neelima Pandey
LinkedIn Groups
ReplyDelete* Group: CIO Forum
Management buy-in is critical to success. Developing specifications is also crucial. Avoid customization - adapt your business processes to the new system as far as you can. Seasoned software providers have multi-user experience so their product processes are very likely "best practice". Data migration can be challenging but it is necessary. Organizational buy-in requires communication, frequent progress updates and training to get users familiar with the new processes. Have a Champion for the new system.
Posted by John Spencer
LinkedIn Groups
ReplyDelete* Group: CIO Forum
Along the lines of some of the other comments here, management buy-in coupled with well-documented user requirements are probably the two key ingredients to a successful ERP implementation. Adding to Neelima’s comment, I believe that it’s all too easy for “scope creep” to occur and focusing on the “must-haves” will make the project more straightforward and easier to complete successfully. However, the “nice-to-haves” should at least be considered during the implementation to ensure the architecture will support them later on. As for later on…plan on additional spending after the implementation as such systems are as ever-changing as the businesses that they help run. I’m not saying you should customize an ERP system (it’s costly and makes software upgrades that much more difficult), but rather that there will be continued tweaking, deployment of additional features, and possibly additional modules added after the main package is up and running. Many people overlook this last piece completely and fail to account for it when budgeting for such systems.
Posted by Tom Smith
LinkedIn Groups
ReplyDelete* Group: CIO Forum
I believe I read this somewhere that around 70% of ERP fail. And someone in this forum has identified the reason as user awareness and resistance to change.
In my experience over communication is the best approach to inform users of the change coming. Get users involved early in the stage so they feel important and part of the change.
We as an IT executive have to remember that this is not an IT project, we are the service providers. There is some piece that executives look at but majority is used by the functional person.
Posted by Mohammad Ali
LinkedIn Groups
ReplyDelete* Group: CIO Forum
Of the challenges listed in your blog, user buy-in and resistance to change would be the most critical.
Management buy-in is even more critical, as others have noted, and it has to be active buy-in and support. They must "walk the talk" by participating in the activities of the implementation project and making their best people available to work on the project. On successful projects, the words are there, plus they allocate their own time and assign their top people to the project -- it communicates that the project is truly important.
It is the CIO's responsibility to ensure that this commitment and involvement happens. It often takes convincing, cajoling, and follow-up. One powerful result is that all of management becomes invested in the success of the project.
Posted by Jeffrey Greenaway
My 2 cents
ReplyDelete1. What is there in the game for the team (benefits - monetary & ...). Define this & you will see less resistance & more participation.
2. Identify how MANUAL/Un-Wanted work will get reduced over a period if time & productivity will increase. This will need some home-work, but once you have it ready it will become very clear to team for the value they are adding in the entire process.
3. I totally agree with "John Loughran"
Team will disagree to participate b'cos they always see NO/LESS support from management. Bring the TEAM together (involve everybody) & you will see more participation
Leo Shuster - I agree that Agile is defenitely not for all projects, but it can be used for BIG projects for sure. It's just that you have multiple teams with different Deliverables (working on same GOAL though). I have used Agile for a bigger project (1+ year duration). It takes little time to set, but it works.