Estimated reading time: 2 minutes, 20 seconds

supplyChainPuzzleThis question, asked of Google, got 402,000,000 results. First item on page 1 of I don't know how many pages was “How to Fix a Zipper”. THERE'S OUR ANSWER! KEEP IT SIMPLE. Let's call it the “Zipper Law”.


What do zippers have to do with Supply Chain Management systems? EVERYTHING. The SCM system has to pull together just like a zipper, and, if it doesn't, the whole thing will just be embarrassing.

So you are designing a Supply Chain Management system? In one respect, you are designing something very complex that will take an order all the way through supply partners, inbound transportation, manufacturing, warehousing, delivery and what ever “points” you want to hang on it. You have an electronic superhighway to connect everything; it's called EDI. But if you look at it as a “supersystem”, you are already violating the “Zipper Law”: you aren't keeping it simple.

What about instead thinking of what subsystems you need? Each subsystem stand's on it's own and performs a specific task. Now, draw a flow chart. Shop for modules that are used to working with other modules. In other words, for example, do you have a warehouse system that works hand in glove with your outbound transportation system?

Can you find an ERP that does everything? Good question. Remember, ERP's are usually designed by people who probably never worked in the supply chain. Something along the way may need modification. Then it starts to get complex.....the Zipper Law again.

 

It will all boil down to your design and your resources. Instead of one huge project, why not several “agile” projects? One of these agile projects would exist to link everything together. Comes down to resources. It's not uncommon for an organization to have one group of developers who need to complete multiple projects. In those situations, how should the group be structured, and how should their work be planned and allocated? Is Agile/Scrum the answer? How does Scrum handle this? One Product Owner, One Product Backlog vs Multiple Product Owners and Product Backlogs? There is a good discussion on INFOQ.COM called Multiple Projects, One Agile Team. The one consensus I get is One Product Owner. I guess you can do two things: (1) do one release of one project (one module), when done, do the next; or (2) Split up your development team; (3) Or a combination of both.

Next, once in operation, you will need to monitor the whole process. Sort of like what electric utilities do to make sure all their “modules” are behaving. An electronic “pulse” goes out to your modules and reports back if there is a problem.

So you have followed the Zipper Law and still everything is not working properly: “Very simple was my explanation, and plausible enough—as most wrong theories are!” H.G. Wells (1866-1946)


Last modified on Monday, 01 September 2014
Read 2085 times
Rate this item
(0 votes)
Tagged under

Visit other PMG Sites:

click me
PMG360 is committed to protecting the privacy of the personal data we collect from our subscribers/agents/customers/exhibitors and sponsors. On May 25th, the European's GDPR policy will be enforced. Nothing is changing about your current settings or how your information is processed, however, we have made a few changes. We have updated our Privacy Policy and Cookie Policy to make it easier for you to understand what information we collect, how and why we collect it.
Ok Decline