Let's assume a simple categorisation of business into trade and manufacturing.
Most of the companies that are active in a category, arrange and manage their processes - despite different fields of business- inspired by a similar and close to optimal pattern. For example all trade companies share the same processes and concepts such as sales region, sales commission, petty cash and etc. The pattern is called "best practice".
Good
Most of the companies that are active in a category, arrange and manage their processes - despite different fields of business- inspired by a similar and close to optimal pattern. For example all trade companies share the same processes and concepts such as sales region, sales commission, petty cash and etc. The pattern is called "best practice".
Good
Now, imagine that you have designed and implemented information software for 25 trade companies so far; naturally resulting in your extensive knowledge of trade firms' processes and requirements -put simply, best practice. In other words, you do know what the customer wants and needs.
What happens if you decide to design a comprehensive information system for trade firms? As you know their requirements and best practices, supported by the trade business knowledge and understanding which you have already earned during last 25 implementations, you design a model that, with minimum complexity and maximum clarity, covers most of the a typical trade firm' processes. Not only your model but also your user interface are efficient and understandable by the customer.
What happens if you decide to design a comprehensive information system for trade firms? As you know their requirements and best practices, supported by the trade business knowledge and understanding which you have already earned during last 25 implementations, you design a model that, with minimum complexity and maximum clarity, covers most of the a typical trade firm' processes. Not only your model but also your user interface are efficient and understandable by the customer.
This is what I call a "Comprehensive Design".
Obviously the model doesn't cover all processes in all trade firms but, those non-covered are a small fraction compared to what the model already covers. In fact, your model embraces about 80 to 85% of a typical trade firm's processes which leaves you 15 to 20% customisation during an implementation. The percentages I just mentioned are very famous in ERP world.
Bad & Ugly
Bad & Ugly
Now, imagine a totally different situation: you have designed and implemented information systems for 2 trade companies so far and all of a sudden you decide to design an information systems for trade firms in general. Let's see how your design is.
Clearly, the knowledge of a typical trade firm requirements and best practices which you've acquired during your 2 implementations -even if both were successful- is not extensive. So when designing you have take care of all the possible requirements -which you're not aware of yet- by designing facilities to easily change the behaviour of the model. This is the key characteristic of your design, happening all over your model since you don't know the real world's requirements and need to prepare for meeting them.
Clearly, the knowledge of a typical trade firm requirements and best practices which you've acquired during your 2 implementations -even if both were successful- is not extensive. So when designing you have take care of all the possible requirements -which you're not aware of yet- by designing facilities to easily change the behaviour of the model. This is the key characteristic of your design, happening all over your model since you don't know the real world's requirements and need to prepare for meeting them.
Actually, your model is a "General Design".
It doesn't have a skeleton -the extract of your experience and knowledge- rather it has lots of lots of features that help users customise all the aspects of it and all because you don't know what you'll be facing in a typical trade firm.
There is a design principle stating that "The design and usage complexity of a software is proportional to how much the software is generalised." In other words, the more general your design the more difficult its development and usage.
Because it is complex and doesn't have a real structure, the result is not a software that has a shape but such a flexible set of -sometimes inconsistent- customisation features that it hardly has any shape. Practically, you have to create a new software out of all the customisation features, In every implementation using the general design.
Conclusion
There is a design principle stating that "The design and usage complexity of a software is proportional to how much the software is generalised." In other words, the more general your design the more difficult its development and usage.
Because it is complex and doesn't have a real structure, the result is not a software that has a shape but such a flexible set of -sometimes inconsistent- customisation features that it hardly has any shape. Practically, you have to create a new software out of all the customisation features, In every implementation using the general design.
Conclusion
- Comprehensive design is based on business knowledge, understanding the target market requirements and best practices and experience.
- Comprehensive design is easily grasped by users and it is easy to use.
- General design is based on a considerable technical knowledge, little business knowledge and incomplete understanding of the target market requirements and best practices.
- General design is complicated and not friendly from the user's perspective.
"Do not generalise. Generalisations are generally wrong." -Butler Lampson
No comments:
Post a Comment