January 15, 2018 at 9:07 pm
Comments posted to this topic are about the item Customize Software or Process
January 16, 2018 at 1:16 am
I work in a big organisation and I've seen the IT department, especially the software development part, to increase in spending from a mere £120K to more than £2M a year (thanks to an army of contractors). I work for lawyers and they were in the impression that 1) their time were more valuable than contractors and 2) throwing monies at contractors will automate their daily task to the point where they could go away with less legal secretaries.
Needless to say that not only the developing went crazy (we had to hire more managers to "slow down" the processes) but the improvement in the bottom line were non existent. The issue with lawyers is that they are very competent in politics and in their particular domain of law but lack very basic understanding of finance or anything IT. In the UK, personal lawyers are paid between £35K and £90K with a median of £45K. A PA or a legal secretary is in the range of £11K to £22K. Now compare that with the cost of a contractor (£400 a day --> £100K a year) and you see that the claim to justify such expenditures of "by automating this process that take us 30 seconds we are going to make an economy of £1.5M" is pretty ridiculous. Especially when the business get accustomed to have contractors and "forget" that they are not supposed to be permanent. This lead to projects been delayed or replaced by ever more ambitious projects.
Software wise, contractors tend to be more qualified than permanent staff which leads to a gap in knowledge when they leave. The firm needs then to keep on hiring new contractors or keep the existing ones in order to maintain the code or a certain level of service. Also, by the time a certain "improvement" has come to fruition, the stuff that the contractors did a year and a half ago, that was supposed to bring in economy "£1.5M", is not relevant anymore and need to be replace by new workflows.
As far as I'm concern, to hire IT software developers to adapt and heavily modify a software, when your main domain is not IT, is a bit like for someone to hire car mechanics to transform their Ford Sierra into an hybrid SUV 4WD. Maybe this person believe that their Ford Sierra has aged nicely and is cheaper than a brand new SUV. This person might feel that petrol is too expensive and that a hybrid would be cheaper. But anyone with a bit of common sense would agree that although it is possible to transform a Ford Sierra into an hybrid SUV 4WD, we all know that in the long run, modifying your own car to this extend is much more expensive than buying a brand new one. In the end, you might have to adapt to the fact that you won't be driving your trusted Ford Sierra anymore ...
January 16, 2018 at 8:01 am
The other issue is of a huge concern and generally a huge PITA for users and that can all be described in a simple, very well worn statement...
"Change is inevitable... change for the better is not".
My favorite example is the "Ribbon Bar" in Microsoft Office. Such a thing was a great idea but it now takes many more (totally unnecessary) clicks to do many common tasks never mind actually finding the correct ribbon to use for a task because certain functionality actually seems to be on the wrong ribbon.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 16, 2018 at 9:33 am
Kyrilluk, great story. I can help a client get the right system for their organization. The client doesn't need to know IT, but what they must know are the details of their own business and clients. Nothing else will suffice. Anyone in business should know every intimate detail about how clients pay them, and how they deliver services to clients. You would think that all business owners or managers would know these basics, but no: some clients luck into business success.
Of course, the way to avoid runaway software projects is by using agile delivery methodology. I can see how lawyers can be bad, but the worst type of clients I have ever seen are doctors. They are smart and confident and they think they know everything.
Industry standard, off-the-shelf systems should always be considered for implementation. My advice is to consider that the system was probably designed by experts in your field. If they implement a workflow differently than you do it, there was probably a good reason. Your way might be a competitive advantage, but it is more likely that you are wrong.
January 16, 2018 at 10:11 am
As a developer I wrestle with this all the time. Should my clients go with custom or off the shelf? As the computer revolution matures, it seems the answer is increasingly off the shelf for more and more companies. I don't like that this is where things are going because a) it means more and more control over our lives by fewer and fewer people and b) less work for me. But the economics of the situation are hard to resist.
Also, I find that, sometimes, even when the client thinks their business processes are different, they really aren't. I have worked on custom applications and only later discovered that the whole rationale for the project was based on a faulty understanding of the client's business model -- by the client! Once their real needs have been revealed through a long process of back and forth, it becomes apparent that an off the shelf solution would have ultimately been a better fit.
The three biggest mistakes in life...thinking that power = freedom, sex = love, and data = information.
January 16, 2018 at 10:24 am
GeorgeCopeland - Tuesday, January 16, 2018 9:33 AMMy advice is to consider that the system was probably designed by experts in your field. If they implement a workflow differently than you do it, there was probably a good reason. Your way might be a competitive advantage, but it is more likely that you are wrong.
I wish you were right. In my line of business it seems like all the dorks of the world collided in the development department, but none of them understood the industry, nor cared to ask the future buyers. But since the entrance toll is very high the buyers (us) don't really have options. We picked the least bad software/service provider. That doesn't mean we are happy with what we are served. For this reason alone I consider the work-groups of stakeholders gathered from each buyer to be vastly superior in expertise. The designers of our software tools are not. And they prove it every time we meet and for every new tool they build.
Which brings me to: Yes, it should always be considered which is the least expensive: To change the off-the-shelf software (or build your own!), or to change the habits of employees, or the employees altogether.
It is just that I have realized that we will never buy a piece of software if it doesn't fit the way we are already working... simply because the ones doing the decision making in this buying process doesn't like to get their habits and laziness challenged.
January 16, 2018 at 10:39 am
Hi,
In my career, I have participate in several ERP implementations with different roles: user, key user, developer, BPM and DBA. Those implementations have different level of customizations. In fact, my personal believe is that every ERP needs some software customizations to fit in a specific industry, due to, the functionallity out of the box, of any ERP, can´t cover all the processes. With more specialized or focused industry, the more software customizations will be required.
From the point of view of the final user, you will ask for a customization that make all your process with the click of a button. The classical phrase that I heard is: What is the gain, in terms of effort or amount of work, of changing the system? And it is valid, due to, in fact in general, it will be more work to do for the same process.
From the point of view of the IT, the less level of customizations, the better. This is due to a hevily customized system will require extra support contracts to keep the customizations under maintenance in the case of the need of technical support. Plus if you need to perform a migration to new releases of the product, it will be easier with a small number of customizations. I know company cases that prefeer to stay in older versions of their ERP due to the complexity to migrate.
A rule of thumb, stats that, if you perform more than 30% of customizations, the chances of a failure in the implementation, raises to double.
In conclusion, if we talk in terms of success ratio, It is better to customize processes than software. This not means that you will avoid software customizations, but you will need a thight control over them. Another rule of thumb, is: if the software customization, add value to the process, then proceed.
Miguel.
January 17, 2018 at 10:55 am
Many times I think about this "why re-invent the wheel?" If it has already been done then COTS is the way to go. Custom software is great for extending the use of existing software and systems via API calls. It is also good to extremely customized applications. Otherwise IMO it is usually the wrong approach.
January 17, 2018 at 3:16 pm
Oh man, this is a good one. This is the problem that never seems to go away. Everybody has the best way of doing something. Apparently, we Americans are worse at it then the Europeans according to a survey I read maybe 20 years (still true?). The Europeans were/are more amenable (and smart IMO) in adjusting their internal processes to adapt to new software instead of the other way around which is how it's usually done here in the U.S. You would think that management would want to take advantage of the opportunity to improve a process and the wholesale opportunity this can provide. Instead, it usually follows the path of least resistance (which is to not disrupt the status quo) and you can end up with an even worse process that's been 'Frankensteined' to an older one that nobody is happy with in the end, tens of millions of dollars have gone down the drain (the vendor and consultants win of course), careers are over, tears shed, friends lost and plenty of emotional scars for anyone involved in the project. Dramatic? Its' an understatement of the reality.
I can see militantly preserving your propriety business process that makes you money but your HR process? Procurement? Help Desk? etc. etc. I suppose it comes down to a lack of will or ignorance on management's part to push through an implementation plan when it meets resistance and the IT people for not doing adequate process analysis and planning or just not adequately educating management about the opportunity.
January 17, 2018 at 4:46 pm
HighPlainsDBA - Wednesday, January 17, 2018 3:16 PMOh man, this is a good one. This is the problem that never seems to go away. Everybody has the best way of doing something. Apparently, we Americans are worse at it then the Europeans according to a survey I read maybe 20 years (still true?). The Europeans were/are more amenable (and smart IMO) in adjusting their internal processes to adapt to new software instead of the other way around which is how it's usually done here in the U.S. You would think that management would want to take advantage of the opportunity to improve a process and the wholesale opportunity this can provide. Instead, it usually follows the path of least resistance (which is to not disrupt the status quo) and you can end up with an even worse process that's been 'Frankensteined' to an older one that nobody is happy with in the end, tens of millions of dollars have gone down the drain (the vendor and consultants win of course), careers are over, tears shed, friends lost and plenty of emotional scars for anyone involved in the project. Dramatic? Its' an understatement of the reality.
I can see militantly preserving your propriety business process that makes you money but your HR process? Procurement? Help Desk? etc. etc. I suppose it comes down to a lack of will or ignorance on management's part to push through an implementation plan when it meets resistance and the IT people for not doing adequate process analysis and planning or just not adequately educating management about the opportunity.
On the other hand, I've found that a lot of 3rd party software (even the proverbial "shrink wrapped and highly supported" stuff) is absolutely terrible. I've also found that many supposed "process improvements" induced by such software are not improvements at all and have caused delays, errors, unnecessary complexity, and the need to hire additional staff. Just because a process is old, it doesn't mean that it's broken or can be improved upon. Don't get me wrong... it's always a good thing to do a sanity check. Just don't let the sanity check become a bit of insanity.
--Jeff Moden
Change is inevitable... Change for the better is not.
January 18, 2018 at 9:58 am
Jeff Moden - Wednesday, January 17, 2018 4:46 PMHighPlainsDBA - Wednesday, January 17, 2018 3:16 PMOh man, this is a good one. This is the problem that never seems to go away. Everybody has the best way of doing something. Apparently, we Americans are worse at it then the Europeans according to a survey I read maybe 20 years (still true?). The Europeans were/are more amenable (and smart IMO) in adjusting their internal processes to adapt to new software instead of the other way around which is how it's usually done here in the U.S. You would think that management would want to take advantage of the opportunity to improve a process and the wholesale opportunity this can provide. Instead, it usually follows the path of least resistance (which is to not disrupt the status quo) and you can end up with an even worse process that's been 'Frankensteined' to an older one that nobody is happy with in the end, tens of millions of dollars have gone down the drain (the vendor and consultants win of course), careers are over, tears shed, friends lost and plenty of emotional scars for anyone involved in the project. Dramatic? Its' an understatement of the reality.
I can see militantly preserving your propriety business process that makes you money but your HR process? Procurement? Help Desk? etc. etc. I suppose it comes down to a lack of will or ignorance on management's part to push through an implementation plan when it meets resistance and the IT people for not doing adequate process analysis and planning or just not adequately educating management about the opportunity.On the other hand, I've found that a lot of 3rd party software (even the proverbial "shrink wrapped and highly supported" stuff) is absolutely terrible. I've also found that many supposed "process improvements" induced by such software are not improvements at all and have caused delays, errors, unnecessary complexity, and the need to hire additional staff. Just because a process is old, it doesn't mean that it's broken or can be improved upon. Don't get me wrong... it's always a good thing to do a sanity check. Just don't let the sanity check become a bit of insanity.
Agreed. If adequate process analysis was done you/whomever would have presented management with some kind of metric based rationale to justify the change and the value it's expected to provide; then after the implementation (before everyone is high-fiving each other) some kind of assessment is done to measure it's effectiveness.
January 18, 2018 at 11:24 am
Jeff Moden - Wednesday, January 17, 2018 4:46 PMOn the other hand, I've found that a lot of 3rd party software (even the proverbial "shrink wrapped and highly supported" stuff) is absolutely terrible. I've also found that many supposed "process improvements" induced by such software are not improvements at all and have caused delays, errors, unnecessary complexity, and the need to hire additional staff. Just because a process is old, it doesn't mean that it's broken or can be improved upon. Don't get me wrong... it's always a good thing to do a sanity check. Just don't let the sanity check become a bit of insanity.
A lot of it is. I'm amazed it sells and more amazed no one does a better job.
Viewing 12 posts - 1 through 11 (of 11 total)
You must be logged in to reply to this topic. Login to reply