Title page: 1 Table of contents: 3

TABLE OF CONTENTS -

CHAPTER ONE: INTRODUCTION 1.1 1.2 4 1.3 1.4 A short introduction: Briefing for Financial accounting: 6 4 -

Briefing for Management accounting: - Summary difference between them: 7

CHAPTER TWO: INTRODUCTION OF STANDARD COSTING 2.1 The Concept of Budgeting and Budgetary Control: 15 2.2 Standard Costing Vs Budgetary Control: 15 2.2.1 Similarities between Standard Costing & Budgetary Control: 15 2.2.2 Differences between budgetary control and standard costing: 15 2.3 Material and Labour Cost Standards : 16 2.4 Utility and Limitations of Standard Costing : 17 2.5 Summary: -

19

1 What is an Enterprise System? Organizations today depend on information systems that help them carry out their operations efficiently and reliably and keep information updated and available. Some of these systems have been developed internally and cover just a small fraction of the organizations processes or data. They are often not well integrated with other systems and require a substantial amount of manual work to complete the business processes. Increasingly, however, large-scale standard packages are replacing the smaller and specialized solutions. From 1985 to 1997 the share of large organizations using packaged enterprise systems has risen from about 30% to 95%. When Hydro Agri Europe introduced its SAP enterprise system in 1999, it replaced around 120 applications that were used all over Hydros 17 sites in Europe. Whereas the packages in the past were only used by large organization, we now have software intended for small and mid-size companies as well. A survey of European mid-size companies shows that the adoption of packaged enterprise systems increased from about 27% in 1998 to more than 50% in 2000. With the introduction of light versions and accelerated implementation tools in recent years this trend has continued and few organizations are now running their businesses without packaged software. An enterprise system is packaged application that supports and automates business processes and manages business data. They come with pre-implemented and customizable modules that reflect best practice for common business operations. Business data from different functional areas are integrated and kept consistent across the organization. A characteristic of enterprise systems is their complexities both in terms of business data and in the way they affect the organizations business practices and individual work tasks. The term enterprise system is often used synonymously with enterprise business application or with the more restricted term enterprise resource planning (ERP) system.

Enterprise systems were supposed to streamline and simplify business processes. Instead, they have brought high risks, uncertainty and a deeply worrying level of complexity. Part of the attraction of enterprise systems has been the opportunity for management to impose best practices and standardized procedures universally and so eliminate the chaos of inconsistent homegrown practices.

Online Exclusive
INFORMATION TECHNOLOGY

The Trouble With Enterprise Software

Has enterprise software become too complex to be effective?
By Cynthia Rettig Email this page
Posted August 8, 2007. Reprint 49101 (buy permission to copy from your own original).

TECHNOLOGY has always been about hope. Since the beginning of the industrial revolution, businesses have embraced new technologies enthusiastically, and their optimism has been rewarded with improved processes, lower costs and reduced workforces. As the pace of technological innovation has intensified over the past two decades, businesses have come to expect that the next new thing will inevitably bring them larger market opportunities and bigger profits. Software, a technology so invisible and obscure to most of us that it appears to work like magic, especially lends itself to this kind of open-ended hope. Software promises evolutions, revolutions and even transformations in how companies do business. The triumphant vision many buy into is

that enterprise software in large organizations is fully integrated and intelligently controls infinitely complex business processes while remaining flexible enough to adapt to changing business needs. This vision of software lies at the core of what Thomas Friedman in The World Is Flat calls the Wal-Mart Symphony in multiple movements with no finale. It just plays over and over 24/7/365.1 Whole systems march in lock step, providing synchronized, fully coordinated supply chains, production lines and services, just like a world class orchestra. From online web orders through fulfillment, delivery, billing and customer service the entire enterprise, organized end to end that has been the promise. The age of smart machines would seem to be upon us. Or is it? While a few companies like Wal-Mart Stores Inc. have achieved something close to that ideal, the way most large organizations actually process information belies that glorious vision and reveals a lookingglass world, where everything is in fact the opposite of what one might expect. Back office systems including both software applications and the data they process are a variegated patchwork of systems, containing 50 or more databases and hundreds of separate software programs installed over decades and interconnected by idiosyncratic, Byzantine and poorly documented customized processes. To manage this growing complexity, IT departments have grown substantially: As a percentage of total investment, IT rose from 2.6% to 3.5% between 1970 and 1980.2 By 1990 IT consumed 9%, and by 1999 a whopping 22% of total investment went to IT. Growth in IT spending has fallen off, but it is nonetheless surprising to hear that todays IT departments spend 70% to 80% of their budgets just trying to keep existing systems running. According to a multiyear study of over 400 companies by MIT researchers Jeanne Ross, Peter Weill and David Robertson,3 IT departments tend not to be innovative leaders within organizations, but rather conservative forces, viewed by business executives as cost sinks and liabilities. In many companies, it takes the IT department one to two

years to implement a new strategic initiative hardly the agility companies are striving for. The research shows the typical IT structure is so dense and extensive that its often a miracle that it works at all. The researchers observe: Legacy systems cobbled together to respond to each new business initiative create rigidity and excessive costs. Every change becomes a risky, expensive venture.

THE PROLIFERATION OF COMPLEXITY

How did this happen? James Cordata, who has written extensively about the information economy, points out that as work became more complex and specialized over the 20th century, the use of data numbers and facts as fodder for more and more analysis and factbased decision making intensified. And digital technology was perfect for this kind of world.4 Of course, digital technology not only supported that complexity but also played a large part in actually creating it, weaving a continuous web of unending data. More computers are better than fewer remains a key belief of American business, Cordata says. There are no limits to how much is good. Management became accustomed to the idea that buying more computers and more software would continue to cut costs and improve operations. But there are limits, some of which are inherent in the nature of software itself. Software is code, lines and lines of code that runs sequentially. Building software programs entails accumulating more and more code. Much of the seemingly boundless complexity of enterprise software is founded on conditional branching (if-then statements) and a hierarchy of interacting objects, all of which manipulate information in a logical succession of small steps. Each step contains explicit instructions. To build software, programmers routinely break down processes into discrete steps, effectively systematizing and standardizing how work is done. An entire sequence of such instructions works more like a calculator than a thinking machine. Thus the socalled intelligence of digital technology arises not through magic, nor, in more contemporary terms, through some emergent or self-organizing principle, as some would believe. The result is not greater than the sum

of the parts. Rather, its more akin to Adam Smith's division of labor and Frederick Taylors scientific management, a process dependent on relentless analysis and rationalization of the work to be done. General software programming used in enterprise systems may contain intricate branching and handle a huge number of conditions, all of which allows it to control a certain amount of complexity. It does not, however, tolerate ambiguity, inconsistencies or illogical conclusions. To be sure, there are fuzzy logic programs, dynamic simulations, genetic algorithms and neural nets with subtler powers, but a vast amount of software working in todays large organizations is not of these more advanced types. In fact, enterprise software systems are more likely to succeed at relatively straightforward tasks such as procurement and order processing. As the problems get more complex, so does the software that solves them. It is estimated that for every 25% increase in complexity in the tasks to be automated, the complexity of the software solution itself rises by 100%.5 Business users and management inevitably want changes in their automated processes as their needs and markets evolve. And they expect to be able to customize their software to fit their own needs. Software is infinitely malleable, says computer historian Martin Campbell-Kelly.6 This is in theory true; however, as enterprise software becomes increasingly comprehensive and complex, the costs and risks involved in changing it increase as well. No single person within an organization could possibly know how a change in one part of the software will affect its functioning elsewhere. Softwares supposed flexibility and unending ability to manage complexity contributed to the discrepancies between the great expectations and mediocre reality that plagued the first round of implementations of enterprise resource planning systems. In the middle to late 1990s, U.S. corporations rushed to purchase and install such systems. These systems Germany-based SAP Aktiengesellschaft's is the most common promised to eliminate the complexity of multiple operating systems and applications by replacing them with a single set

of interconnected modules to run the financial, manufacturing, human resources and other major functions of a typical multinational corporation. Theoretically, a single monolithic system would seamlessly connect various distinct and geographically separate locations through private networks. Companies understood that they could customize these systems as needed to suit their unique business processes. That was the hope. But these massive programs, with millions of lines of code, thousands of installation options and countless interrelated pieces, introduced new levels of complexity, often without eliminating the older systems (known as legacy systems) they were designed to replace. In addition, concurrent technological and business changes made closed ERP systems organized around products less than a perfect solution: Just as companies were undertaking multiyear ERP implementations, the Internet was evolving into a major new force, changing the way companies transacted business with their customers, suppliers and partners. At the same time, businesses were realizing that organizing their information around customers and services and using newly available customer relationship management systems was critical to their success. The concept of a single monolithic system failed for many companies. Different divisions or facilities often made independent purchases, and other systems were inherited through mergers and acquisitions. Thus, many companies ended up having several instances of the same ERP systems or a variety of different ERP systems altogether, further complicating their IT landscape. In the end, ERP systems became just another subset of the legacy systems they were supposed to replace.

THE COSTS OF IMPLEMENTATION

ERP systems were expensive, too, costing companies more than they had ever paid for software when costs had been based on perworkstation usage. But that price tag was dwarfed by the installation charges, because companies had to hire brigades of outside consultants, often for a number of years, to actually get the software up and running. While the average installation cost $15 million, large 7

organizations ended up spending hundreds of millions of dollars. Even such large expenditures did not guarantee success, however. In fact, 75% of ERP implementations were considered failures.7 Try as they might to measure the productivity gains of ERP implementations or IT in general, researchers have yet to arrive at any coherent or consistent conclusions. One problem is that there is little statistical evidence, especially about whether the benefits of ERP implementations outweigh the costs and risks. Researchers have even suggested that ERP implementations are so difficult that those companies that actually complete them with relative success gain a competitive advantage in the marketplace.8 It seems that ERPs, which had looked like the true path to revolutionary business process reengineering, introduced so many complex, difficult technical and business issues that just making it to the finish line with ones shirt on was considered a win. All that complexity and all those options created another conundrum. As Nicholas Carr famously pointed out in his book, Does IT Matter? Information Technology and the Corrosion of Competitive Advantage,9 simply implementing the plain-vanilla business processes that your competitors have does not provide any competitive advantage. On the other hand, as many companies learned the hard way, customizing the already complex ERP software created yet more complexity and even larger risks. Without intimate knowledge of how the integrated pieces of these modular software packages actually worked, customizing could lead to in-house bugs and glitches that were hard to foresee and expensive to fix. Perhaps even worse, customization made changing the software later or upgrading to a newer version far more difficult, and in some cases prohibitively expensive. Christopher Koch, executive editor of CIO, tells the story of one head of a corporate SAP installation group who bragged that he had his installation time down to a mere three months for various facilities around the world: It didnt matter that he was honing his skills on a 10-year-old version of the software because the costs of upgrading are so huge tens, even hundreds of millions of dollars, or as much as it cost to install the stuff in the first

place that he keeps installing old versions of the software so that it will line up with the old software they already have.10 Unexpected bugs present another type of difficulty that increases with complexity. Robert Pool, technology journalist and author of Beyond Engineering, explains it this way: Its possible to go through a program line by line and make sure that each individual instruction makes sense but it is not possible to guarantee that the program as a whole has no flaws.11 The average professional coder makes 100 to 150 errors for every 1,000 lines of code, according to a Carnegie Mellon study conducted by Watts Humphrey.12 That means for every million lines of code there would be 500,000 mistakes. Software developers do extensive testing on the paths users seem likely to take and correct many of these errors. Nevertheless, they cannot test or even anticipate every possible usage path, so released software inevitably contains unknown defects. Civilization depends on software. So although much software code is poorly written, you cant just stop the world to fix it, says Bjarne Stroustrup, the Danish-born computer scientist who designed the popular C++ programming language. On the other hand, Stroustrup does concede that muddling along is expensive, dangerous, and depressing.13

THE VAGARIES OF DATA

The data that software processes and generates is another constant and growing problem. Estimates of errors are astoundingly high. Single systems can have error rates of 50% or more from myriad sources everything from mistyped data to stale information to data placed in the wrong fields within the database structure. But the really nasty, intractable data problems erupt when companies integrate multiple data sources, as was necessary for ERP implementations, so that they could have all their product, inventory and production records stored in one place. Because of differing formats, conventions, abbreviations and so on, such integrations can result in 100 or more records that actually point to a single product or customer. In the case of enterprise system implementations, data problems alone precipitate many of the failures

perceived by business users and much of the added expense as well. Overwhelmed by the sheer difficulty and complexity of the new software itself, companies literally forgot about the data, as executive John Nicoli of Trillium Software in Billerica, Massachusetts, describes it, until the tail end of the project, thereby necessitating enormous reworking to properly clean up and integrate the data.14 And with corporate data stores doubling every three years, such data issues are only compounding. Is enterprise software just too complex to deliver on its promises? After all, enterprise systems were supposed to streamline and simplify business processes. Instead, they have brought high risks, uncertainty and a deeply worrying level of complexity. Rather than agility they have produced rigidity and unexpected barriers to change, a veritable glut of information containing myriad hidden errors, and a cloud of questions regarding their overall benefits. Leaders in computer science are clearly worried. Complexity is death, says Chuck Thacker, one of 16 technical fellows at Microsoft Corp. We are hanging on with our fingertips right now.15 Business executives, however, simply want to continue to believe that technology will lower costs, improve processes and reduce the size of the workforce. They dont want to understand IT issues. In part, this is because technology requires special skills and intellectual talents that are quite distinct from those needed to understand and manage business organizations, markets and strategy. But it is also because executives do not like to hear about the downside of technology. Observes Jim Shepherd, senior vice-president of Boston-based AMR Research Inc., Senior managers often dont particularly want to be told that theres a high risk and that theres a great deal of expenditure involved in minimizing it.16 Yet the only sure thing about new technologies and the changes they introduce is their uncertainty. In summarizing decades of research into technological change, MIT Sloan School of Managements Wanda Orlikowski and the National Science Foundations Suzanne Iacono conclude that changes involving technology are both profoundly complex and uncertain.17

10

For their part, CIOs and their managers rate aligning IT with business strategy as their number one priority. They struggle year after year to prove the value of IT to the business side of the organization. Yet the cost overruns, delays and outright failures of enterprise systems have if anything widened the digital divide between IT and the executive suite.

THE NEXT NEW THING

The proposed fix for these problems the next new thing is serviceoriented architecture. Basically, SOA proposes to overcome the problems involved with updating and changing legacy systems by building modular cross-system business processes. These processes would connect the relevant pieces of functionality from various IT systems, thereby making it easier to change processes to adapt to new business goals. But technical realists point out that many difficult technical problems must be solved before SOA can become the backbone for a new strategic architecture, including robust protocols for accessing the applications, high quality integrated data stores and a sound methodology for managing the overall process. Researchers Ross, Weill and Robertson admit that most companies are in the early stages of a four-part transformation to SOA that may take many years even decades to realize.18 The estimates of how long this will take reflect a growing acknowledgment of just how deep and radical are the organizational changes these technological innovations mandate. It is a process of adoption and adaptation that by definition cannot occur overnight. Nor, conclude the researchers, can companies skip a step. Given that only 6% of companies have made it into the later stages, this model would suggest that companies are in for a long haul if they are to escape the tangle of technological complexity inherent in large organizations today, and it will be a journey fraught with cultural as well as technical problems. The timeline itself for this kind of transformation may just be too long to be realistically sustainable and successful. The dynamic business environments of today, where whole industries and markets can undergo radical changes in a matter of a few years and the horizon for

11

corporate strategies has shrunk from 10 years to three to five, makes it questionable whether companies can actually maintain a focused strategy long enough to align their core business processes with IT. Technical problems raise additional questions about the feasibility of such an undertaking. The hallmark of service-oriented architecture one might reasonably argue its entire raison dtre is the fundamental modularity of its software business processes. A selfcontained business process adopts parts of the functionality from multiple enterprise applications to automatically complete a set of tasks. For example, a single business process might begin with an order from a customer on the Internet in a web services system and send it to manufacturing in an ERP system. The same business process would set up delivery in a logistics system and then send all the relevant information to billing in an accounting system as well as a customer relationship management system. Companies would build (or purchase) business modules for their core processes. They would then be able to easily change these processes, snapping out and in functional pieces of code from enterprise systems in Lego-like fashion. The Lego dream has been a persistent favorite among a generation or more of programmers who grew up with those construction toys. Unfortunately, however, software does not work as Legos do. For one thing, a unit of software code is not similar to other software code in terms of scale or functionality, as Legos are.19 On the contrary, code is widely various and heterogeneous. It contains different numbers and types of connections to other code, more like fractals, as Victoria University of Wellington researchers James Noble and Robert Biddle describe it, than Legos, with their uniform connections. Software engineering expert Robert Glass sees another problem with the Legos idea: The notion of reusable software works on a small scale. Programmers have successfully built and reused subroutines of standard functions. But as software grows more complex, reusability becomes a difficult or impossible task. It is simply a problem too hard to be solved, a problem rooted in softwares diversity.20

12

Complexity is a deadly software killer, says Yale computer scientist David Gelernter, and he argues that managing complexity is more of an art than a science, and a difficult one at that, especially given the monumental real-world systems todays software attempts to automate.21 And to the extent that these service-oriented architectures use subsets of code from within ERP and other enterprise systems, they do not escape the mire of complexity built over the past 15 years or so. Rather, they carry it along with them, incorporating code from existing applications into a fancy new remix. SOAs become additional layers of code superimposed on the existing layers. That means it is possible that a process will fail at some point due to some fault in the layers below, and in order to understand and fix that problem, software engineers will need to deal with the layers of enterprise applications below the modular business processes. Culturally, this long-term plan calls for closer and closer communication and collaboration between the IT and business sides of the organization. While much to be desired, this has proved difficult in the past, and with increasing complexity in software systems, it is unlikely to improve by itself in the future. Differing backgrounds and perspectives, goals, even vocabularies all hamper efforts to improve communication across this internal digital divide. Biases intrude: A recent study by Forrester Research Inc. of Cambridge, Massachusetts, found that only 28% of CEOs thought their CIOs were proactive or creative in terms of business process improvement.22 Forresters advice to CIOs is to get more deeply involved in the business issues and educate executives on what IT is and what it actually does. Sound advice, no doubt, but it may be time for business executives themselves to become more proactive. Executives could educate themselves more about technology. They could send promising younger executives to executive programs designed to teach business people how to better understand, communicate with and capitalize on their IT. And business schools, too, could do better at teaching the interdependence of business and IT. At present, however, corporations see in softwares seductive invisibility and seemingly open-ended

13

flexibility a never-ending frontier of promise, where hope triumphs over reality and the search for the next new thing trumps addressing difficult existing problems. And hope, unfortunately, has never been a very effective strategy.

REFERENCES
1. 2. T. Friedman, The World Is Flat: A Brief History of the Twenty-First Century (New York: Farrar, Straus and Giroux, 2005), 128. J. Dedrick, V. Gurbaxani, and K.L. Kraemer, Information Technology and Economic Performance: A Critical Review of the Empirical Evidence, ACM Computing Surveys 35, no. 1 (March 2003): 18. J.W. Ross, P. Weill, and D.C. Robertson, Enterprise Architecture As Strategy: Creating a Foundation for Business Execution (Boston: Harvard Business School Press, 2006), 11. J.W. Cordata, Progenitors of the Information Age: The Development of Chips and Computers, in A Nation Transformed By Information, eds. A.D. Chandler and J.W. Cordata (New York: Oxford University Press, 2000), 206-208. R.L. Glass, Facts and Fallacies of Software Engineering (Boston: Pearson Education, 2003), 58. M. Campbell-Kelly, From Airline Reservations to Sonic the Hedgehog: A History of the Software Industry (Cambridge: MIT Press, 2004), 198. K-K Hong, Y-G Kim, The Critical Success Factors for ERP Implementation: An Organizational Fit Perspective," Information & Management 40, no. 1 (October 2002): 25. L.M. Hitt, D.J. Wu and X. Zhou, Investment in Enterprise Resource Planning: Business Impact and Productivity Measures, Journal of Management Information Systems 19, no. 1 (summer 2002): 71-98. N. Carr, Does IT Matter? Information Technology and the Corrosion of Competitive Advantage, (Boston: Harvard Business School Press, 2004).

3.

4.

5. 6.

7.

8.

9.

14

C. Koch, The Monopoly That Matters More Than Microsoft, blog in CIO Magazine, Nov. 13, 2006, http://advice.cio.com/the-monopolythat-matters-more-than-microsoft. 11. R. Pool, Beyond Engineering: How Society Shapes Technology (New York: Oxford University Press, 1997), 137. 12. W. Humphrey, TSP: Coaching Development Teams (Boston: Addison-Wesley, 2006), 186. 13. J. Pontin, Bjarne Stroustrup: The Problem With Programming, Technology Review (January-February 2007): 22. 14. J. Nicoli, interview with author at Trillium Software (Billerica, Massachusetts), August 8, 2005. 15. S. Rosenberg, Anything You Can Do, I Can Do Meta, Technology Review (January-February 2007): 45. 16. M. Wheatley, ERP Training Stinks, CIO Magazine (June 1, 2000). 17. W. Orlikowski and C.S. Iacono, The Truth Is Not Out There: An Enacted View of the Digital Economy, in Understanding the Digital Economy: Data, Tools and Research, eds. E. Brynjolfsson and B. Kahin, (Cambridge: MIT Press, 2000), 355. 18. Ross, Enterprise Architecture As Strategy. 19. S. Rosenberg, Dreaming in Code: Two Dozen Programmers, Three Years, 4,732 Bugs, and One Quest for Transcendent Software (New York: Crown Publishers, 2007), 94-95. 20. Glass, Facts and Fallacies of Software Engineering. 21. D. Gelernter, Mirror Worlds: Or the Day Software Puts the Universe in a Shoebox ... How It Will Happen and What It Will Mean (New York: Oxford University Press, 1992), 51. 22. S. Shay, CEOs Rate IT: Steady But Uncreative, CIO Magazine (April 1, 2007): 20. 10.

Cynthia Rettig was director of knowledge management for B2B consulting company Canopy International of Newton, Massachusetts. She has consulted to software companies for over 20 years. She can be reached at smrfeedback@mit.edu.

15

16