Once upon a time, there was an ERP company called ABCD. ERP was a revolutionary concept. It integrated data from all over the business, integrated processes across departments. It was good.
The implementation had 2 kinds of consultants – Functional Consultants, who understood business processes and translated them in ABCD terms. And Technical consultants, who developed applications that the standard could not take care of. These applications were supposed to be the exception rather than the norm, bcs the product was very well researched and prepared to meet most business needs.
Over a period of time, it became apparent that every implementation will have to have some technical applications built especially for that customer.
Over a period of time, it became important to contain project costs, and customers started questioning the existence of 2 consultants – functional and technical. Customers wanted to know why the same person could not do the development.
On the other hand, technical consultants wanted to do something more meaningful, and that “more meaningful” was “functional work” .
Therefore, it made common sense to let the technical and functional consultants learn and do each others’ work. Right? Wrong.
This model overlooked a few small points. These were:
· Coding is like Poker. It takes 5 minutes to learn, and a lifetime to master. Good technical skills cannot be learnt in a matter of a few weeks or even months. Coding is specialized activity. It takes a good coder to write a good code. And the difference between good code and bad code is the difference between Microsoft and Apple. You may inundate the market with volumes. But that will not make you the “customer delight” company. Likewise, you may have years of coding experience, but still not be the coder who writes easy to implement, and easy to update code quickly, effectively, efficiently. Mediocre coding costs more money than most organizations can imagine.
· There is only one way to know what works and doesn’t work with a business process. Its called experience. To know what will and will not work in an technical product, you don’t have to look at the flowcharts or the product features. You have to look at that incongruous being called “The user”. Implementations are a study in user behavior. Users are not a part of most implementation projects. Which means that as the functional consultant, you have to know already what users will and will not do with your product.
· If you combine half baked process knowledge with good coding skills, or if you combine good business knowledge with less than excellent coding skills, you will get the same result – a mediocre implementation, with limited scalability. Which means that you will need an upgrade faster. And because your processes and/or your code are not easily scalable, you can look forward to a nice upgrade project costing just a few million dollars. Because you wanted to scourge on that extra consultant. What was that poem again, for want of a nail, the battle was…. ?
So what’s the point? The point is that one needs to go back to the basics –To be penny foolish and pound wise. To understand the importance of both kinds of skills, and that excellence in both of them has to be valued *equally*.
The implementation had 2 kinds of consultants – Functional Consultants, who understood business processes and translated them in ABCD terms. And Technical consultants, who developed applications that the standard could not take care of. These applications were supposed to be the exception rather than the norm, bcs the product was very well researched and prepared to meet most business needs.
Over a period of time, it became apparent that every implementation will have to have some technical applications built especially for that customer.
Over a period of time, it became important to contain project costs, and customers started questioning the existence of 2 consultants – functional and technical. Customers wanted to know why the same person could not do the development.
On the other hand, technical consultants wanted to do something more meaningful, and that “more meaningful” was “functional work” .
Therefore, it made common sense to let the technical and functional consultants learn and do each others’ work. Right? Wrong.
This model overlooked a few small points. These were:
· Coding is like Poker. It takes 5 minutes to learn, and a lifetime to master. Good technical skills cannot be learnt in a matter of a few weeks or even months. Coding is specialized activity. It takes a good coder to write a good code. And the difference between good code and bad code is the difference between Microsoft and Apple. You may inundate the market with volumes. But that will not make you the “customer delight” company. Likewise, you may have years of coding experience, but still not be the coder who writes easy to implement, and easy to update code quickly, effectively, efficiently. Mediocre coding costs more money than most organizations can imagine.
· There is only one way to know what works and doesn’t work with a business process. Its called experience. To know what will and will not work in an technical product, you don’t have to look at the flowcharts or the product features. You have to look at that incongruous being called “The user”. Implementations are a study in user behavior. Users are not a part of most implementation projects. Which means that as the functional consultant, you have to know already what users will and will not do with your product.
· If you combine half baked process knowledge with good coding skills, or if you combine good business knowledge with less than excellent coding skills, you will get the same result – a mediocre implementation, with limited scalability. Which means that you will need an upgrade faster. And because your processes and/or your code are not easily scalable, you can look forward to a nice upgrade project costing just a few million dollars. Because you wanted to scourge on that extra consultant. What was that poem again, for want of a nail, the battle was…. ?
So what’s the point? The point is that one needs to go back to the basics –To be penny foolish and pound wise. To understand the importance of both kinds of skills, and that excellence in both of them has to be valued *equally*.
8 comments:
No why does this sound familiar?So with you on the need for appreciating both Technical and Functional skills.
-Seema( from the ABCD company:))
Looks like you are facing some heat at office!
It is not about learning each other's skill or able to perform other's task. It is all about appreciating each other's contribution in overall implementation. You cannot run a car just on two front wheels for long.
very appropriate observations. You should be my manager :-)
you missed out another skill (do not want to call it so but not able to find another good word for it) - Project Managers in ERP implementation projects. Remember RR days?
You have approached the entire subject from a new angle.
You hit the nail on the head, girl! I would so love to use this in my exit email!
Post a Comment