Domain Knowledge

Domain Knowledge is the knowledge of a particular industry

domain

Domain knowledge is the knowledge about the environment in which the business organizations operates, and it encompasses the understanding of the industry dynamics, history, sectors and segments, business model, competitive landscape, value chain, customers, supply chain, challenges and the industry specific strategies of the target enterprise.

Domain knowledge is necessary because it provides the ability to make good judgments and quick decisions and empower the users to deal with complex business situations.  For implementing e-commerce project it is necessary to learn about the business that you are trying to automate on the internet.  Gaining understanding of the industry means a smarter analysis, clearer logic underlying business decisions, closer attention to key dimensions of implementation and operation, and more disciplined performance management.

On the lighter side, here is a joke:

Get Domain expertise

Get Domain expertise

There was a family with one kid. One day the mother was out and dad was in charge of the kid, who just turned three.

 
Someone had given the kid a little ‘tea set’ as a birthday gift and it was one of her favourite toys. Daddy was in the living room engrossed in the evening news when kid brought Daddy a little cup of ‘tea’, which was just water. After several cups of tea and lots of praise for from father for such yummy tea, kid’s Mom came home.
 
Dad made her wait in the living room to watch the kid bring him a cup of tea, because it was ‘just the cutest thing!!’
 
 
Mom waited, and sure enough, the kid comes down the hall with a cup of tea for Daddy and she watches him drink it up, then she says to him, ‘Did it ever come to your mind that the only place that baby can reach to get water is the toilet??’
….Mothers know!
 
Moral Of The Story:  Domain knowledge is very important!  Else your project may fail.

Communicating between end-users and software developers is often difficult. They must find a common language to communicate in.  It is necessary to learn the jargon (vocabulary)  to communicate effectively.   The consultant may play an important role to bridge the gap between business executives and software engineers.

Examples of Domain Knowledge that may require for a project in the respective business category.
  • Automotive Domain.
  • Banking Domain.
  • Education Domain.
  • Engineering Domain.
  • FMCG Domain.
  • Retail Domain.
  • Telecom Domain.
  • Travel Domain.

In ERP / e-commerce project, domain knowledge is knowledge about the environment in which the target system operates. Domain knowledge is important, because it usually must be learned from software users in the domain (as domain specialists/experts), rather than from software developers. Expert’s domain knowledge is transformed in computer programs and active data, for example in a set of rules in knowledge bases, by knowledge engineers.

Replacing ERP Software?

Are you planning to change your ERP vendor?

ERP Implementation tips

ERP Implementation tips

Replacing system management software is like visiting a medical clinic for injection, painful but necessary.  First, try to get upgraded version if any, from your existing ERP vendor.  Probably this means more investment, but worth considering.  Once you rule out this option, and decide to look for new ERP software, consider the following points:

  1. Once again define the new requirements, this time make a function wise list.  For instance, accounts, material, sales, and so on.  It is important to do the ABC analysis, A essential list, and C is wish list.  Remember if everything is A, you will have to pay for the customization, so let go of some point as wish list.  Share the list with the new ERP vendors, and try to match.  Here the trusting the new ERP partner is important that you want the truth.
  2.   Do some business process improvements.  Do not (do not, no this is not a spelling mistake, just to emphasise) automate without improving your existing methods.  Chances are you will automate the mistakes; this means ERP will do mistakes faster.  This exercise is called BPR (business process re-engineering).  All the problems with the existing system are in fact opportunities for improvement.  Ensure that you are aware of the issues, and that the new ERP software system will help resolve them.  Learn more about BPR here  http://www.dnserp.com/b__p__r_.htm.
    Do some BPR before ERP

    Do some BPR before ERP

  3. Stay focused in defining the scope.  Module wise write down master, transactions, and reports.  Again, do ABC analysis of the same.  See sample scope given here http://www.dnserp.com/dns_scope.htm.  FAQ: Can I change the scope?  Ans: Yes, but after discussing with the ERP supplier and before starting to implement.
  4. Select your task force.  Motivate them, yes allocate a budget.  Offer incentive.  Involve key people at the start.  Write important milestones.
  5. Size of the ERP company is not that important, small or big, what is important is how important it is for them to make your ERP a success.
  6. Arrange for a demo with your own inputs and try to match the report – at this stage without customization.  About eighty percent of your requirements should be met.  So prepare your own data to input for the demo run.
  7. Brainstorm with your senior management to identify potential reasons of failure, and take steps to guard the same to reduce risk.
  8. Assign one (or better two) main ERP coordinator/s, dedicated resource/s.  Consult domain expert and other consultants such as tax, ISO, 6-sigma, etc.  Ensure their valuable time is available.  Study http://www.dnserp.com/implement_erp.htm.
  9. While evaluating make sure the implementer/s are also interviewed and their time is committed.
  10. ERP implementer and ERP coordinator team should have project management skill.  Ask ERP vendor to show their track record of other similar size ERP success story, I mean show the document that was used to track ERP project management in the past.

Hope you will find this ERP tips useful and will share with others, by using the social icons given below.  Let us know your comments, add point that we might have missed out, your feed back will be appreciated. 

I lost one hour. Seriously, whole of America did.

At 2 a.m. this morning, clocks moved forward an hour with the shift from standard time to Daylight Savings Time (DST).   This is logical change and not adaptive change. This is logical because everyone is changing their timetable.  For instance, getting up one hour early due to ‘Daylight savings Time’ is logical.  No huge adjustment of life priorities is triggered.  Our body clock can change without much difficulty.  But if you decide to get up one hour early to do meditation or go for swimming is difficult, because it is adaptive change.  In both examples same thing ‘get up one hour early’ is involved.

Using new technology such as Blog is adaptive change.  No matter how hard you try some people are not comfortable using facebook or LinkedIn.  You must have seen the clip that shows expert secretary changing from typewriter to a PC, and throwing monitor, because she is used to do the carriage return.  Or changing from manual system to automatic ERP system is a painful transformation.  Changing from legacy way of marketing and using the digital platforms is not an easy because it requires adaptive change.

Daily we make logical changes.  We use our training to solve routine problems, such as dealing with customer’s negative feedback, or altering action plan when sales target is not achieved.  We do customer survey and make a road map to address the issues.   But note that these examples are pertaining to external changes.

On the other hand adaptive changes are transformative, which compels us to change from inside, in the mind.  We want to reign in our temper because it is affecting our relationships with customers and colleagues, but not matter how hard we try we cannot ‘control’ it.  Our frustration spills over, and now we have to fix the damage.

Anupreksha or the cognitive behavioral therapy is a psychotherapeutic approach, which aims to solve problems concerning dysfunctional emotions, behaviors and cognitions through a goal-oriented, systematic meditation procedure.  There is empirical evidence that this is effective for the treatment of a variety of problems, including mood, anxiety, personality, eating, substance abuse, and psychotic disorders.   We can treat ourselves by a meditation technique; there are treatments for specific psychological disorders.

Only by fixing our inner feelings of frustration can we make an adaptive change.  We could decide to use cognitive behavioral therapy or Anupreksha, or some other method for the internal change.  To make such changes you need to recognize when you are facing an adaptive change, that requires subconscious level of thought and effort.

The real leadership, the kind that surfaces conflict, challenges long-held beliefs, and demands new ways of doing things-causes pain.  When people feel threatened, they take aim at the person pushing for change. As a result, leaders often get hurt both personally and professionally.

(Reference: Leadership on the Line, renowned leadership authorities Ronald A. Heifetz and Marty Linsky, Wikipedia, and Preksha meditation system).

Why change before ERP?

BPR or Business Process Re-engineering is also referred as ‘change management’.

DO BPR before ERP

Change legacy method before you automate

If you automate a procedure with ERP,  it will speed up the results.  But, what if the legacy procedure itself was ‘incorrect’?  After ERP, now the ‘incorrect’ procedure will do wrong things  faster.  Is that what you wanted to achieve by deploying ERP?  Correct method to implement ERP is first to identify a process, second improve.  Third automate with ERP.

Let me give you few examples:

In one small company, the purchase officer was in habit of ordering material on phone.  In ERP that is not allowed.  If PO is not made, stores cannot enter data about material received.  For about three months, everyone tried his or her best to resist change.  Then the MD came to our rescue.  He instructed security that if the truck comes without bill, or without our Purchase Order reference number: “Do not allow the material to come inside the factory”.  After a couple of incidents where the material was returned, all the suppliers understood that the company was serious.  They started writing the PO reference number on their challan-cum-invoice.  Challans alone is not accepted.  Vendors and third-party insisted on getting the PO or JO from the purchase officer.  In other words, change was enforced by the top boss.  Benefit: Return on investment realized.

Classic example: “In DNS ERP software, we gave a link in the Purchase Order (PO), to pickup rate from the Purchase quotation.  User’s reaction: “I do not have time to prepare purchase quotations in ERP”.

Then, how ERP will help you with the pre-purchase module?  You have to change.  As a top person with authority, you should put your foot down and say, ‘nothing doing, we have invested in ERP to improve our business processes and not mimic old way of working in new ERP business logic.’

Another example: In one project, the user insisted on making challan to give materials to customer.  Our team said this is wrong and that you have to make CCI – Challan cum Invoice.  He did not budge.  He made our programmer change.  Now after six months he realized the mistake and again requested for the change back to the way it was.  He was charged Rs. 50,000/- for making changes.

This is a good example (of sticking to bullock-cart): In one company accountant was using an old fashion account-centric program, where she was allowed to change / edit / delete a transaction.  She expected ERP to do the same.  Without realizing, the very benefit of ERP is lost.  ERP is multi-user software.  Now we are planning to give access to branch offices.  The edit facility is a serious problem because user will ‘misuse’.  If you have a motor bullocks are not required, it is that simple (see picture above).

I can go on and on…..ask yourself a question: What are the opportunities for improvement?  Please write down for each function, say in accounts, in purchase, and so on.  Resistance to change is natural but we are intelligent human being, we have the reasoning mind.  Take ERP implementation as opportunity to carry out changes.

Why change? Conventionally, the legacy system that organizations use today, captures only transactional data like ‘what is bought’, at what price and when. The RFID technology enables capturing the event data through wireless sensor (reader) on each item and communicates to the ERP server on ‘Real-Time’ basis. We should “change” our businesses; Use the power of I. T. to radically redesign our business processes in order to achieve dramatic improvements in their performance.

Old rule: “we pay when we get the invoice”.  New rule: “we pay when we get the goods”.   In many growing companies in developing countries like India, they receive material with a ‘Challan’ (piece of paper that just mentions quantity) and later the supplier gives the invoice. The material is accepted, by stores based on (stupid) Challan; and may be even issued to production. While account section is not making any entry because ‘invoice’ was not received at that time. It is necessary to persuade vendors to give the bill along with the material. That is, insist on Challan-cum-Invoice (CCI).  Only if the vendor is under excise rule, stores will receive material with Challan-cum-Invoice. If vendor is not under excise he may send bill with Challan.

What to do? Now these vendors need to be educated for sending the bill so that accounts entry in ERP and that in stores will always match. One of our DNS users understood the significance and importance and took initiative to send some 400 mail merge letters to all suppliers to ensure that they send the bill as per the Purchase Order Schedule (which was prepared in ERP) citing the PO number on the bill. Even the security (security guard) was told not to allow any material to enter if not accompanied by a bill. It took sometime for all concerned to understand the ‘reengineering’ but after sometime everybody said it was a change for better!

Re-engineering while implementing ERP triggers changes of many kinds, not just of the business process itself.   Job designs, organizational structures, management systems, and most importantly ‘Attitude changes’ – anything associated with the process – must be refashioned in an integrated way. In other words, re-engineering is a tremendous effort that mandates change in many areas of the organization .  “Don’t be afraid to give your best to what seemingly are small jobs. Every time you conquer one, it makes you that much stronger. If you do the little jobs well, the big ones will tend to take care of themselves”.  (by Dale Carnegie).

In ERP, we try to coordinate parallel function during the process – and not after it is completed. Considering the inertia of old processes and structures, the strain of implementing re-engineering plan can hardly be overestimated. But by the same token, it is hard to overestimate the opportunities, especially for established companies.

Before implementing DNS ERP software one must do quite a bit of BPR. In fact, BPR and ERP implementation goes hand-in-hand. On one extreme, we change the software to suit current business processes – known as customization. On the other extreme, user is ready to change the current business processes and does BPR. The sensible way is to strike a balance somewhere in-between. Please instruct the ERP implementation team to carry out only ‘essential customization’. At the same time, identify old inefficient processes for revamp, and tell the users to adapt to new business processes in view of ERP, since some of the tasks that they were doing would now no longer be required.

Example of top management strictness: In one ERP project, we observed that they took the following approach:  After GO-LIVE, everyone was asked to join ‘new’ company. They are working in a new company, in a new role, and if they could not take on the new processes and working with ERP menus, they should leave after the 3 months probationary period was up. While effective, not always possible, and also an extreme example.

Here is a short story that exemplifies need for change.  Some companies keep on changing ERP instead of changing their legacy procedures.

Crow story: Once there was a Koel sitting on a branch.  She saw a crow running away.  She asked him, why are you running?  Crow said, ‘I am fed up with people around here, I am going to a new place’.  She asked ‘Why’?  Crow said, ‘they are  not good, they do not allow me to seat at one place, they always shoo me away by throwing stone and all that, and so I am going to a new place.’  She asked him, ‘Oh, OK, but did you change the old habit of screaming Ka  Ka  Ka and disturbing people’.  He said ‘No’.  Then she said. ‘in new place also perhaps people will drive you away and you will not benefit by running away from this place’.

Moral of the story:  Change before you automate.

You can share your experience, or comment on this blog.  What do you say?

%d bloggers like this: