The Trouble with Business Process and Software Development

Michael Vizard
Slide Show

The 10 Commandments of Large-Scale IT Transformation

Help focus your IT organization's attention on the most fundamental aspects of program management.

At its highest level, a piece of enterprise software is a digital abstraction of a business process. When the business process is well-defined, the development of the enterprise application usually goes pretty well. The trouble comes when the business process is either not well-defined, or the business wants to spend an inordinate amount of time reengineering a commonly-accepted business process.

According to Deepak Purohit, Associate Vice President of the SAP practice within the Enterprise Solutions group of the IT service firm Infosys Technologies, this latter issue comes up more often than IT people might think. A business may have developed a certain way of conducting a business process over the years. But more often than not, there is a more commonly accepted way for doing that same process already baked into a packaged application. Changing the process inside the application will incur massive amounts of expense just to customize something that doesn't really add a whole lot to the business.

That's not to say every business process is a packaged application. But the difference between success and failure in large-scale projects frequently comes down to being able to distinguish between commonly-accepted business processes that should not be customized, and areas where customization of a business process can make a real strategic difference. And that's where the experience of a business consulting firm can make all the difference.

But even once everyone agrees to what the optimal business processes should be, things can still go horribly wrong. Infosys has come up with a list of Ten Commandments that should be resolutely followed during any large-scale IT transformation project. And a fundamental tenet of those commandments, said Purohit, is to make absolutely certain that the people overseeing the project are independent of both the business executives that funded the project and the IT teams that implemented it.

Without that independence, there is real no objective analysis of the state of the overall project. Business executives will hold things up in pursuit of features that might not be strategic, while IT teams may simply want to get things done regardless of how well or fully implemented they actually are.

With all that can wrong, it's no wonder why so many projects fail. But business is often won and lost over which vendor has the most efficient processes in place. So while the stakes are high, to the victors go the spoils.

Add Comment      Leave a comment on this blog post
Sep 28, 2011 11:20 AM Nikolas Josh Nikolas Josh  says:

When working on the development of an application, if you are improving an older version or redesigning and existent one, as a business man you always have to think about how much value you really add to the final product. I have been working on a dll file extension application and I haven't considered the fact that I don't bring much value to the end result. I wasn't able to sell the application at the price I asked for and I ended up loosing a lot of money.


Post a comment





(Maximum characters: 1200). You have 1200 characters left.



Subscribe to our Newsletters

Sign up now and get the best business technology insights direct to your inbox.