Implementing an enterprise tool (PLM, PDM, ERP, MRP, MES, or any other TLA:)) within an organization is one of the things that keeps many people awake at night. There are many reasons for this as I mentioned in my previous blog posts Looking at Investing in PLM?. However, in many of the discussions I have been a part of just this year I do see the common problem of us unnecessarily increasing the difficulty of the implementation project. Our ambitions are much greater than the reality that we live in which causes us to attempt to implement too much too quickly. We know the benefits of implementing an enterprise solution in our organizations and want all the benefits it promises in the first iteration. Without a proper phased milestone implementation strategy (one brick at a time), most of these projects will never leave the initial prototyping phase to be used in a production environment.
One of my main focuses working with clients on a PLM implementation recently is to provide an Agile approach which at SSI is core to everything we do. We look at the requirements and picked the top 1-3 things that will provide value in a relatively short time frame. This allows us to get results quickly, learn from our mistakes (yes there will be mistakes) and note things we simply did not consider originally.
No Two Implementation are the same
There have not been two implementations the same because everyone runs their business differently. There are many reasons for this such as the type of ships, type of clients & contracts, number of ships in the series, culture, tradition, etc. Some of these changes create a fundamental difference in the product data model we structure in the PLM which needs to match the client’s business.
PLM literature tells you that a PLM implementation requires a business transformation. I do agree with it; however, it is a journey not a flick of a switch. The first few phased milestones will require minimal changes (relatively speaking) to the way business is being run. As time goes on we add more functionality to enable and in some cases incubate the new business that you will transform into. This is a really important strategy since if you try to do too many changes at the beginning, the implementation will have a high probability of failing.
As mentioned, no two implementations are the same; however, the similarity of the first few phases are high. I believe this is true because the core foundation of the information as well as the overall process is similar enough within our industry. Also there is an understanding that the first few milestones should attempt to use out-of-the-box functionality with no to very little customization.
With PLM implementations the areas which are usually in the first iteration (3 months – 1 year) are:
- Publish completed Engineering data from ShipConstructor (not WIP)
- Document delivery
- Feedback loops
- Client review
- Change management
- Production Planning activities
The follow-on priorities start to change significantly. Some companies decide to enhance the features and functionality of the previous milestones while others decide to continue to implement additional features such as:
- Hull Effectivity
- Configuration Management
- Requirements Management
- Integration with ERP/MRP
- Supplier portal
These areas are first prioritized in order to provide the first level of scheduling. Then, within each area we decompose the functionality we need to its smallest implementable and measurable unit. With this decomposition we are left with the items we plan and schedule for our phased implementation. This provides a good strategy to deliver production ready functionality very quickly and transitions the business to use the new tools and processes we have defined in manageable and consumable bite sized chunks.
Implementing a major enterprise system in an organization can have significant benefits to your company. However, this potential of huge benefit also comes with some risk. To reduce risk you will need to make some hard decisions and prioritize what is important to your organization. This may seem challenging to reduce the initial implementation to only a handful of items but if you do not do this you will increase the risk and potential of failure.
Continuing with the decomposition of each of your priority items to its smallest implementable unit will allow you to implement using industry standard agile strategies. This will allow you to build, measure (validate), learn, and repeat very quickly.
This is the only method I would recommend using for implementing any enterprise system.