Project Integration
I think I can share an interesting story that would help relate the topics of last week's class to the business world. Currently, I'm working on a project that will be implemented on a large scale. There are many challenges involved in the development of all the processes. I can't completely divulge what the nature of the project is due to legal liabilities, but needless to say it has many integration issues.
The first issue I run into on my work is how to turn the old system's outputs into the new system's inputs. Since the new system is being designed to be more informative than the previous one, there is a challenge to develop a systematic way to match more information to the output accurately and quickly.
The next problem is then taking your new input and turning that into meaningful output. This sounds like a very straightforward task. If you take a step back and look at it from the macroscopic level, all the systems and processes feed into other systems and processes. Any setback on the input side will occur on the output side as well (since that becomes the input to another system).
These first two steps are basically your actual process development steps. At this point you have a working, albeit completely non-integrated, system. Here is where I believe the contents of the class come in. How do you effectively transition into a system described above? The complete system is in the middle of a chain that cannot be abrupted for more than a few days at the absolute worst. One solution that I believe most closely falls under the hybrid method would be to employ the strategy that we are using.
We create and entire mock up of the system. This is sort of like running it parallel but only behind the scenes. We feed the information into this and the real system at the same time. Afterwards, we analyze how the output is coming out of both systems to see if it's compatible. Once the outputs match up, we know we have a system that is ready to be switched over.
Even at this step you do not have an integrated system. No one other than the people creating it knows how to use it properly. So more mock-ups are made. These are mini versions of what the complete package will look like. Everyone who will use the system is trained on his or her own customized mock up of the system.
The last piece that needs to be addressed after all this is done is the maintenance of the system. Technical staff must be involved in the whole setup. Luckily, they can be involved in the actual creation of the process so they do not have to be individually trained. They will work on it for a long time making it work right from the get go.
Basically, what I’m getting at in this story is that “Abrupt” implementation projects are not always quick or cheap. The project I am currently working on has been in the works for years and has had several employees working on it. While the implementation (and hopefully integration) will be abrupt, the creation is anything from it. I believe any truly abrupt project is destined to fail in a true competitive business setting. Failure to plan is definitely not a good way to succeed at business.
Comments