Supply Chain Challenges (I.C.I)
So you have done everything right. You have gathered standards, documented your processes and deployed a successful integration. Now what? Do we just sit back watch the data flow and sip soft drinks?
I don’t think so. You will now start to handle exceptions. This means errors. Most likely you will start to have repeating errors. Someone will have overlooked or misunderstood something, and now every time this thing happens there is an exception.
Because computers won’t stop doing something, just because it isn’t working. Once you set an automated application on its way, it will keep going until you tell it to stop and do something else. This where the ICI process comes in. (ICI is pronounced icky)
Integration Continuous Improvement
The ICI process needs a couple of things. It needs data about the issues. (frequency, impact, what is done to resolve them, etc) It also needs a couple of people that meet together to review this data, data around the issues and exceptions, and a regular, repeating time to meet.
Ideally, attendees will include someone from support, best if it is someone that actually solves the problems, not just a manager. Someone from development, again not a manager, but someone that will be able to code solutions. Someone from integration, this is us. And a manager, (yes we do need them), to authorize the work and effort.
The agenda works like this. First item is a report of solutions put in place since the last meeting. The developer and integration engineer make this report and the support person can respond to verify that they have seen this resolved. There will also be the report of errors, that should bear out this report. Second item is to go over the list of exceptions. They should have a rating of frequency, difficulty, impact to the customer, and impact on the company. Based on this, the members of this meeting decide what should be handled and addressed in this ICI cycle. This work is then assigned to the developer and or integration engineer based on the best way to resolve, and the meeitng concludes.
The first time I encountered this process, we met twice a week. Within a month, we were meeting once a week. We kept meeting at that frequency for a long time. A year at least. During this time, we improved so many issues that our partners were amazed at how fast we could turn on an issue. The support group loved us, the account managers loved us. Heck, everyone loved us. What was not to love, a small team that had no other purpose but to solve problems.
Of course we also had our regular tasks and there were times that we didn’t have solutions what we could implement in a week. But when our company acquired a competitor, we were already in place working to solve issues that came up between the two companies.
There are other processes and ways to manage projects. People who use SCRUM or Agile programming can use that model to address integration issues. And this can be done with any model, but the purpose here is two fold. First to reduce the meeting to its essentials. Second, to give in a frequency and capability to make a diference.
What are other processes that you have used? What made them good or bad?
Subscribe to "The Integration Engineer" by Email
Find out about the tools and services available at The Integration Engineer's Consulting site.
