- June 23, 2010
- Posted by: admin
- Categories: Blog, Business Dynamics
“We make solutions that help you achieve 200% productivity, and reduce your HR costs by 37%!”.
This is not the first time you’ve read a line like this. And you can tell that its a standard IT firm pitch, because it doesn’t say:
“But implementing such a solution is gonna cost you three times what your HR did, and it will take at least 6 months to get an alpha version, after which you’ll be finding bugs in it for the rest of your life. But hey – our contract is only 9 months,so we go scott-free afterwards!-business automated!”
How many times does this story need to repeat itself before someone can figure it out. Most business failures today are attributed to poor workflow management, exorbitant payrolls, AND plain DUMB solutions that further complicate the business process instead of automating it. The best part – you pay for it to happen, because ‘the tech guy knows best’ :S.
Lets face it, no one knows your business better than you do, not even Mr. IT himself, with a million ‘technical’ abbreviations appended to his name. So why leave him in-charge. Why do people silently put up with IT bloopers of this sort? What, according to you, are the ‘best practices’ that can help avoid such situations?
The most common resultant of such situations is that small/medium business entrepreneurs avoid IT altogether, owing to the negative (but true) perception of ‘high-tech hole in my pocket’ associated with it. How do you feel entrepreneurs can best-gauge exactly how much time/effort/cash they should spend at automating their business process.
Most importantly, how would you scale your ROI on your IT spending (if you do, at all) – or do we simply consider it an inescapable expense (or a bad decision)and ‘move on’?
Looking forward to constructive feedback. Feel free to share experiences.
z
15 Comments
Comments are closed.
It is always easier to blame a system than a person, for a business blunder when it comes to BPA/BPR. However the blame of failure should not be put on these systems, but on poor implementation and understanding of the solutions. BPA/BPR should only be used to get people back to the “core work” that they are responsible for. Let me give an example.
So you have a salesforce; they are constantly sending emails to new clients, completing multiple forms for new clients, giving clients updates on their standing, and other tasks that are not at the core of their job. BPA/BPR can be used in this case to automate emails to new clients, auto-fill forms based on information in a CRM, create a self-serve area for exisitng clients, and other automations that may be needed to allow the team to focus on the core task; building their relationships with new and existing clients.
With this example, there were a few things left out. The most obvious one was a planning session, where a full businessplan for the change is created, including the scope of the project. Also, letting staff know what change will happen, how it will automate (explaining that job automation does not lead to job elimination), and what the benefit is. Finally; training.
What I am showing is that BPA/BPR failure is not due to the systems offered today, but on the reasons behind using them, the planning, and misunderstanding behind them.
Please add if I am missing anything!
Sorry to miss the ROI section…
ROI on IT would depend on industry, would it not?
For example, I.T. for web-based businesses are costs of doing business, where as I.T. for a shoesmith would not be.
The way I prefer to scale ROI is using the “Risk Of In-action” method where it looks at what you stand to lose, in market share, employee happiness, competitiveness and other factors. I find this much more valuable than just a simple decison based on financial returns.
I am not saying that financial returns do not matter in decisions, but it is given that if these areas are met, finances will not suffer. Let me simply explain…
Market share – relates to financial returns
Employee happiness – relates to costs of finding new employees etc.
Competitiveness – relates to financial returns
Other factors – can relate to both cost and returns.
If Russia Federation of Silicon Valley is going to success, in my opinion cost reducing is not good idea because companies need to invest R & D in order to become more productive and competitive.
I learned the hard way for several decades of SYSTEM implementations the following GOLDEN RULES:
1. An electronic computer software package is not a system. One cannot acquire a system by acquiring computer capability.
2. One acquires a system by conducting systems analysis, achieving a design and processes by working with the people who will run the system. This is hard work and time consuming. Processes are improved and made more efficient by modifying user behavior not by automating it.
3. Once system and analysis and system design are complete one chooses tools to assist in running the system. The adequacy of a computer tool is driven by the requirements of the most efficient system design.
4. The biggest mistake implementation teams make is to believe they are buying a system when they buy a software tool or let the software drive the systems analysis process. That is like asking a mechanic to drive a wrench from New York to St. Louis. It has resulted in millions of dollars wasted and plummeting efficiency in many organizations, large and small.
5. It is necessary to design a system and processes unique to the company to meet user requirements before going shopping for computer tools. If you do not you will be pigeon-holing your company into a COTS mentality and become a slave to the company that owns the source code. If you want anything changed it costs a big buck.
Links:
http://www.smalltofeds.com
The biggest problem in IT is the software. And the biggest problem in the software is software development. The question contains inside the toughest problem of software development.
Your question can be split in some “smaller” questions:
– How to compute “absolute” ROI by replacing a part of the business with software automation?
– What are the problems introduced by the software acquisitions and integration in the business?
The real “big” problem is the hidden in the second: the software development (and configuration) is one (or the) most dangerous domains because of rate of failures and problems.
There are two aspects:
– development shall be done well
– The software acquisition shall watch the suppliers software development process.
There are more problems – software that:
– does not fit to the business
– is not ready on time , quality and money
– has to many defects
– cannot be changed with business need changes
There are some known practices & methods that manage these problems:
– iterative development approaches (Agile and RUP)
– RUP principles for business-driven development
– CMMI Dev– organization level maturity for software developers
– CMMI for Acquisition
Iterative development
– only these types of approaches can give real feedback about software development project progress
RUP principles for business-driven development
– implementation of these principles in a development process will allow to the development to keep the pace with the target business changes and needs
CMMI DEv
– concept was introduced especially for this types of problems
– maturity shall be developed at organization level
– Note: but, this predictability has his costs
CMMI for Acquisition
– CMMI-ACQ, V1.2: “The intent of this widely adopted business strategy is to improve an organization’s operational efficiencies by leveraging suppliers’ capabilities to deliver quality solutions rapidly, at lower cost, and with the most appropriate technology”
Needed “maturity” depend of context. The cost of the software could be 30K or 30M. Maybe for 30K you cannot afford to get CMMI certification, but could be used as a book of knowledge.
The real problem of being agile is that you shall know many things and also you shall know to select what is appropriate for a particular context.
If you have not enough knowledge (that mean a reduced set of skills and instruments) how can you choose the optimal path in context?
It is like in Quality Management, always a cost/benefits analysis shall be done before selecting a process method.
Here is a simple step one can take: get a second opinion!
Zohaib,
Excellent statements & question!
Much has been promised by those selling “solutions” and too often very little is actually delivered. Every IT vendor/consultant can spin a tail of lower TCO and rapid ROI and can wrap cost saving efficiencies around their products and services at the front end but few can actually close a project with these figures becoming reality.
Every vendor has a maturity lifecycle that takes a prospect from “chaos” to “maturity”. The prospect is always in “chaos” and the solutions always ensure “maturity” if you sign. I see three areas of falsehood built into these maturity lifecycle sales pitches:
ONE
The cost of being “mature” is always way beyond what the prospect can afford.
TWO
The complexity of being “mature” is way beyond what the prospect can manage.
THREE
The reality of being “mature” isn’t generally necessary.
Simple solutions are always the best. Improvements in efficiencies, effectiveness and cost can be achieved incrementally and through the implementation of easy to manage processes, techniques and training FIRST – BEFORE you invest in technology.
Salespeople are in the business of selling and most consultants are inseparably conjoined to a vendor/partner (which means they are salespeople for a fixed solution). So when they knock on your door they already know what they MUST fit into your need before you’ve answered their first question or they know anything about your business.
What is needed to maximize IT spend ROI/TCO is find an unfettered partner who will invest time in (1) discovery of needs and then (2) work to understand how your business operates; it’s culture, history, operational balances, attitudes, capacity, capability and tolerance for both change and technology. Only then can you make a wise assessment whether to implement the latest enterprise solution or to sharpen pencils and buy legal pads. Either can be a big improvement and making the best decision is a sign of….maturity.
Jeff
Hey Zohaib, nice question. Hopefully iI am answering it to some extent with the following
1. IT is a tool, not an end.
2. You need a tool when work to be done is
A. Repetitive and therefore processized
B. Complex, needs multiple data points and variables, but remains largely quantitative
C. A human is wasted on the task if there is no room to grow or develop
D. Response time earns you more money.
3. IT is not the do-er. Peolpe are and they are intuitive, inventive and talented/ skilled. So, IT does not replace them, it only makes it easier for them.
4. ROI is simple. See point 1 and 2D simultaneously. If they both are fulfilled, it works fine. Example – a 2 $ an hour employee does not need to be on SAP. Its a waste of money on both ends. So if s/he gets a small repeater which increases their productivity (earns/ 2D), then its fine. Else not justified.
5. Only the user can deliver the ROI. So focus on matching tools to people, even at the risk of becoming an obsolete organization. Because that is much better than becoming a dysfunctional uncreative losing organization.
6. Finally, all of the above are relevant only for small organizations. Scale needs capable solutions. If you are a big business, it is better to move with your IT team.
Thanks
Potential customers have responsibility for:
* Evaluating the ability of a supplier to provide what is needed, in terms of the relevant requirements and constraints: function, quality, value, timescale, etc.
* Ensuring that the product will meet these relevant requirements and constraints, otherwise not pay (or pay less, or be compensated), according to the terms of contract which they have responsibility for ensuring meets their needs.
That’s all they have to do.
Sorry my friend, but you are nothing more that a pain in my ass.
Kind regards,
Edwin
The best practices involving training existing personnel in automation and providing resources and workshops where they can collaborate with developers to lighten their load. Focus on freeing time for personnel to develop relationships with the people they work with, client, vendor and colleague. By improving the productive output of key personnel you can increase the overall capacity of your organization to focus on workflow points that are value added but prior to automation represented a less profitable path than the work that is now automated. Your employees will thank you for alleviating their dreariest of tasks and your organization can reap the bennefits of reduced stress working environments and increased availability of personnel to affect improved processes across the board.
I, for one, as an automator of office tasks know that the business of office automation is not the same business as software development. Oftener than not my macros and scripts shorten a four hour task to fifteen to thirty minutes, but when its over its over I don’t want to spend time creating a tool to manage automations and source code that may never be used again for a code base that could grow to a full time job managing.
Empower your people to get their most dreadful and monotonous tasks done quickly. Don’t pay someone to build an application that does little more than make people fear for their jobs. Find the work that can be done by people once they’ve gained a taste for freedom from monotony. Teach them to automate, or pay me to.
Dear Zohaib,
First of all, thank you for your topical question, you’re quite actually right in terms of inapplicability of such too techy approach to the current business environment. And as a result ignoring rather than embracing of right IT solutions by SME.
I think the problem comes from corporate sector where providers of large and expensive behemoth systems consider themselves as connoisseurs of everything related to business and its automation.
They truly believes that no business unit can operate without their genius systems and the problem is that many large corporations buy it and already on the hook of their clumsy systems and IT infrastructures which in turn prevent the development of more technologically advanced and business-oriented solutions such as SaaS.
Leading vendors were always oriented on developing solutions for enterprise level, neglecting less-profitable SME sector, but I think the key is to make available all those Oracle, SAP and Microsoft know-hows to the SME sectors, preferable through the Cloud as Salesforce did. To turn the focus – their leaders should learn how to think small as well.
It just my opinion.
Sergey
Links:
http://www.levi9.com
Automation is a chaos if not done under the right project managent.
From my experience, most of the automation initiatives that fail are due to poor vision of future load of usage as well as standardization of process. During my stint with Infosys, I involved in manual functioning of processes for at least 4-5 quarters before I came up with first draft of standard procedures and exceptions (recurring and non recurring). A careful review and rework on the standardization took another quarter with close supervision from my managers. Then only a green signal was given for Automation. We have to be double sure of the standard procedures keeping future usage in view.
Once a tool is done, it is expected that the process implementation increases. An automated tool cannot attain its goal if some basic rules are not changed. A revisiting of the basic rules is necessary for efficient usage of the tool. We need to carefully analyse the future number of users
and make provisions for implementing the desirable aspects too.
Another tip is to select those technology platforms which encourage modularity while coding the tool. This allows convenience in adding other functionalities which were not anticipated.
While testing the tool, the time-effort saved has to be carefully scrutinised, Often I have seen the testers overlook some obvious loopholes during prototyping. I recommend that the end users participate actively in the testing process to avoid major reworking at later stages
The problem is that none of the major players in the space could both create an efficient workflow and business management solution and a simple solution at the same time. They were all too busy trying to one up one another on pointless features or formal languages to “automate” business processes. The bulk of business processes for traditional businesses particular small to medium sized businesses have nothing to do with a supply chain they have to do with a service chain and the products produced by the big players have all gone over kill on this solution.
They have also forgotten a key difference between optimizing a solution for the service space as opposed to the product supply space and that is people need to collaborate, collaboration needs to include both social business functions as those managed by a calendar but they must also critically inject actions associated with business workflows directly into the conversation stream. This is precisely what none of the big players are doing adequately or cheaply, primarily because it’s a damned hard problem to solve in a general and scalable way, secondarily because they are applying a solution focused on automating product and supply chain processes to fit service chain processes…the two are related but the complexities of the minority dominates in the space where a much simpler solution is required. One must wonder why a smaller player hasn’t tried to attack this problem, the reason is that most single developers haven’t had the unique experience of developing content or workflow management systems for generalized use (platform design)..to get that experience you need to be in the field for a few years and situated just in the areas where such knowledge could be acquired. Also building such a solution would require patient and focused design time that is often precluded by the limits of resources necessary to allow that design time to occur. The result, catch 22 for any business looking for an efficient solution.
I have been working on a startup that will provide a solution to this problem that allows business processes for the bulk of business automation requirements that integrates workflow, business process and collaboration without requiring IT to a) build the workflows, they can be developed to model existing processes by any person given permissions and can emerge collaboratively as individuals are added to the interaction landscape b) broadcast and receive detailed action streams of business object associated changes with collaboration built into the process and c) enable monitored ability for teams to collaborate securely beyond the firewall.
Hi Zohaib,
I am most familiar with manufacturing automation so IT solutions have little meaning except for when someone has the bright idea they can cross over into the design and implementation of projects that clearly require practical knowledge. I have seen several major business failures because certain processes and imaginary cost savings were implemented that submarined the project.
I was roped into automating a presto-log and pellet mill factory. However, they opted to save money by purchasing used equipment and made it “like new” by sand blasting and painting the equipment before it was delivered to the site. Despite my objections they also opted to use inferior materials (thin walled mild steel ducting etc) throughout the materials conveying systems.
Clue; what happens when sand gets into complex control systems and bearings? The discovery process was rather expensive. Clue; what happens when highly abrasive materials are blown through thin walled ducts? Down time and replacement, not good.
I have seen several businesses dependent on factory automation where the up-front decisions broke the company bank. If you are ever asked to evaluate for purchase take this as gospel. Walk the site, check the PM logs and find the bone yard (where the defunct and scavenged equipment is discarded or gets picked over for ‘useful’ parts).
Software automation is another issue and if your company has partners, do not attempt to immediately universalize their crappy software to make it work for you. Your system works. Do not implement full systems conversions without first getting the thorough feedback of your primary users.
Also, you would not believe how such a simple thing can kill a business. I will tell you something else, paperless systems cost savings are a fantasy. One systems crash or a few software upgrades (block points) and you will really understand the difference between complexity verses simplicity.