My colleague, Duncan Klett, recently wrote the blog titled “Six lessons learned from six failed software implementations.” I completely agree with his lessons learned and recommendations, but I have many of my own! I want to outline two lessons learned from many software implementations that are currently near and dear to my heart. Reporting… So many times I work with clients who are scoping out implementation projects and begin asking users what they think they need for reports from the system. The more people who are asked, the more reports make it on the list. Those reports then begin to take on a life of their own. They become a huge wish list of everything users have always wanted. When it comes time to prototype the reports more light bulbs come on about all the possible reporting capabilities. This is very exciting! (Unless of course you want your project to be completed on-time or on-budget). Even if the project does end up going live with all the great reports (that will solve world hunger and allow users not to actually have to do any work) low and behold the users determine shortly after go live they want to change all the reports. Why would they want to change all the reports, you ask? Well, because they now actually understand how the system really works and they see the actual production data in the reports so they understand it better; then comes the enhancement phase of the project. The enhancement list becomes very long and sometimes costly. Recommendation: I typically try to encourage clients to keep the list of reports to almost nothing, just regulatory, or reports that are required to run business. And even then, don’t involve a wide group of users, but rather stick with true decision makers. Once the system goes live, do a true reporting project to capture and identify all reports. Have a reporting strategy for the life of the system which allows for users to request new reports or enhancements to existing ones. Have a review board to ensure the requests are valid. Review the reports annually or bi-annually to determine usage of reports and anything not used in the last six months get rid of it. This may seem like basic advice, but why don’t we all follow it? How do you handle reporting during a project? Do you have any other advice to share? Super Users… We’ve all heard the term Superuser. Wikipedia defines the term as: “The ‘Superuser’ in enterprise programs (SAP, Oracle) often refers to an individual who is an expert in a module or process within the enterprise system.” I think that is a pretty good definition - Each client I work with discusses having Superusers, however not all client’s actually put a name(s) to that title before a project begins. This could mean failure! If the company cannot define who the Superuser will be in particular business process areas during the implementation then who will actually help define what needs to be implemented, and better yet know what is actually implemented at go live? Post go-live is a nightmare of support because no one actually knows how to use the system and client is reliant upon consultants to teach them; which is both costly and inefficient. Recommendation: Encourage clients to assign a Superuser(s) to a project before the project starts. That Superuser(s) works hand in hand with the consultants and is preferably dedicated to the project. The Superuser would even do some of the development of the system while the consultant oversees. How better to truly learn and adopt the system that “doing it yourself”? That person should also be the ultimate decision maker as it relates to scope and design of system or be the ONE conduit to that ultimate decision maker. By doing this the client should feel ownership of the system and feel it is “theirs” as there is at least one person who lives and breathes the system. What experience have you had with Super Users on projects, either positive or negative? Do you have any other advice to share?
今日のグローバルサプライチェーンリーダーは、想定外の事態を予想すべきことを理解しています。自然災害、規制が突然変更になること、社会的および経済的変化、さらにはサイバー攻撃に備えています。ただし、事象によっては他の事象と比べても、かなり破壊的なものがあります。最近の新型コロナウイルスの大発生はコミュニティを動揺させ、中国の武漢の生産施設での製造に依存する企業を危険にさらしています。この地域の施設が生産遅延の可能性に直面しているので、グローバル企業は代替のサプライヤーを検討しています。新型コロナウイルスの症例数は増え続けており、この地域は封鎖され、輸送および商品の流れが制限されています。その影響も今後のタイムラインも全く不明なため、計画はさらに難しい状況です。非常に多くの人々の生活と健康への支障をきたしているので、企業はその影響をコントロールするために迅速に行動したいという思いを強めています。病気の大発生が今後も予測不能性なことと相まって、より早く知り、より速く動くニーズに新たな緊急性が加わりました。 順次計画における不適切な予後診断 最良のシナリオで...