Karun had written in recently commenting on some points in my recent series on “Rethinking Enterprise Software“. His comments pertain to Visual Biz-ic and Software Components (1 2 3):
In developing a “Visual Biz-ic”, it is useful to think of it as developing the DTD for an XML language. In my business, we started with a DTD for structured finance and then developed the interpreter for it. The DTD is now accepted by W3C and is available at xml.org.
Any business language has two dimensions — horizontal components common to all industries, and vertical components specific to particular industries. For instance a balance sheet is common to all industries. A construct like Average Mileage may only be relevant to the tire industry. Since my industry is banking, I have built the basics of balance sheet constructs in DoubleHelix — our XML language. An asset is simply a schedule table of date, principal due, interest due (and some related fields). A liability is simply a schedule table of date, pricipal to be paid, interest to be paid. All businesses boil down to this. On top of the substructure, we have very specific things such as calculate risk-based present value, etc. etc. which are only really needed by banks. But the basic structure of asset table and liability table is a useful generalization.
What Karun says is absolutely right. We need to think of the components as Horizontal Components and Vertical Components — the former are general-purpose (working across multiple or all industries) while the latter are much more specific to certain industries. Interestingly, there are XML standards being created for multiple industries which could serve as the base for building these components.
Karun once again:
You wrote: “I could visually define the business processes, rules and information flows in my enterprise. Still better, the system could come with a library of business processes from which I could use. While most SMEs do follow some processes, they may not necessarily be the most efficient. Being able to identify other companies in similar segments whose processes and flows could be used can help me define the processes for use in my company. The software would then automatically generate the necessary business objects and logic based on my choices. If required, I could then use English to define special business rules for my company.”
In my company we implemented TQM, but the people we learnt it from made sure that it was people centric rather than process centric. There exist process definition documents, but they are ancillary to the results that each employee is required to do. In every task, the aspects that we measure are some or all of PQDCM — productivity, quality, delivery (per schedule), cost, and morale. We set numeric targets and measure the actual result, and insist on continuous improvements. If we realize something is not being achieved despite the metrics showing improvement, we need to see whether the metrics need to be re-designed / enhanced.
Your tool could begin with the business process design, but each step should have the person and the metric(s) by which it is measured including two dimensions: targets and actuals. That would then feed into each person’s areas (metrics) of accountability. In my company we have a software system where anyone can log in and they will see their metrics and the metrics of those who report to them. ou can click on a particular item to see the support documents (like business process, quality measuring procedures, etc.). This system of being people focused has worked great. Once you only specify the result (in a metric) that must be achieved by the person, it is up to him or her to use creativity and talent to achieve it. If he or she does, the data will record it, and they will eventually be recognized and rewarded. I have also found that poor performers leave of their own accord without any sense of indignence, because it is clear what the performance was. TQM is something every small business should learn — it works wonders.
Maybe you can incorporate some of this in your product if you think it make sense.
Excellent thoughts, and something we should definitely keep in mind when we get to the execution of the enterprise software ideas.
