Are you ready for Big Data Analytics? Reply

Just like any technology cycles, there is widespread interest and hype in Big Data. It is probably most talked about subject (although maybe it’s second to Cloud) in IT circles. I want to acknowledge the importance of a big data strategy. I would rank right up there with ERP –once upon time (be sure to read my blog post on ERP).  Let’s put it this way: Big Data is in its first inning and is playing to win–it still maturing! This is also a wake up call for organizations to take control of their internal data. What is the relationship? Let’s start with understanding basic concept and this is directly from Wikipedia: Business Analytics (BA) refers to the skills, technologies, applications and practices for continuous iterative exploration and investigation of past business performance to gain insight and drive business planning.[1] Business analytics focuses on developing new insights and understanding of business performance based on data and statistical methods. In contrast, business intelligence traditionally focuses on using a consistent set of metrics to both measure past performance and guide business planning, which is also based on data and statistical methods.

Analytics have been used in business since the time management exercises that were initiated by Frederick Winslow Taylor in the late 19th century. Henry Ford measured pacing of assembly line. But analytics began to command more attention in the late 1960s when computers were used in decision support systems. Since then, analytics have evolved with the development of enterprise resource planning (ERP) systems, data warehouses, and a wide variety of other hardware and software tools and applications.

There are plenty of examples available of Analytics enabled companies that save substantive amount of money by understanding the data and using analytical models to gain competitive advantage. Banks like Capital One for instance, use data analysis (or analytics, as it is also called in the business setting), to differentiate among customers based on credit risk, usage and other characteristics and then to match customer characteristics with appropriate product offerings. Harrah’s, the gaming firm, uses analytics in its customer loyalty programs. E & J Gallo Winery quantitatively analyzes and predicts the appeal of its wines. Between 2002 and 2005, Deere & Company saved more than $1 billion by employing a new analytical tool to better optimize inventory. There are many more examples, but these are still very limited if you consider entire corporate world. The above mentioned examples are also very specific and limited in nature. This goes to show that we have yet to exploit the potential of Analytics.

So what is stopping us? First and foremost, it’s our understanding of what we are looking for. We have been treating Business Analytics as a reporting mechanism which is reflective in the type of resources we hired to the training we provide in management schools. Do you remember how many statistics classes were mandatory during your MBA? This is exactly my point! Secondly, we have literally let data get out of our hand. It is too distributed and we don’t know how to bring it together. Lastly, the quality of data itself is a big issue for organizations. Enterprise Resource Planning was supposed to solve this problem by consolidating all front office and back office applications together in single global instance. But we all know that despite of the advancements in functionality and scope of ERPs, we still have several supporting applications (some of them are integrated and some not) and data that resides in them. Then the industry came up with service oriented architecture. A very sound concept and I would put it on equal footing to advent of personal computer (it was different way of thinking about integration and applications). However, we ran into several technical challenges, standards challenges, governance challenges etc. instead of solving problem it created new data type called metadata. We tried to use master data management and data warehouse techniques, but it received partial success.

So now what? As we are trying to get handle on our data, the consumers started getting more and more savvy and willing to share more data in exchange for a personalized service. This is from where concept of Big Data came along. Notice that I’m stating “concept” and not software. Concept is very simple. It is verity, velocity and volume of data has grown exponentially.

So what should we do? Does investment in technologies and integrated platforms like Big Data Appliance from Oracle will provide value? Technology by itself will not. The example you may be familiar with in your organization is Master Data Management initiative. if your organization has gone through it, you will know what type of coordination and collaboration it takes to really realize of MDM benefits. those lessons learned are applicable here. Organizations need to start taking control of Big Data NOW. Here are four good steps to follow:


  1. Understand the data in the context of application. This can be made more manageable if organizations first go through Application Rationalization (read my blog on application rationalization).
  2. Prioritize and sanitize internal data. Try to standardize the data definition across organization. It is difficult said than done.
  3. Bring in your assets that can give you insight into your customers, products, and what is competition is doing. This will require people from different part of organization to come together and really model out what do we want to learn.
  4. Find talent (the most difficult part) that understands statistical modeling. Make sure they understand your product set and have complete understanding of your customer and industry. I think the team approach is very effective including a team statistician, business expert, strategy expert and customer expert. Give the team time to fully understand and model internal data.
  5. Start integrating external data. This is where organizations need to provide tools that can support modeling of “Big Data.” In this context, Big Data is the combination of internal data (structured and unstructured data) and external data (social networks, internet, search trends etc.). This is when you will start to realize the real value of “Big Data Analytics”—when you will be able to contextualize someone’s comment on a Facebook page to your internal data and predict how you can gain customer or personalize your product to an individual. This is very powerful.

Depending on the size of the organization, the complexity of the customer base, depth and width of product set, proliferation of data etc., will determine how long it will take to implement and get ready for Big Data Analytics. It is critical to start now! You don’t have to wait to start realizing benefit until everything is done. You can strategize the phases and thoughtfully determine the slices of data that need to be exploited. Be prepared for some miss-steps and miss-interpretation. That is why it is important to test the hypothesis before trusting the result. Business analytics should be used in the business decision-making process, not just as reporting tool.

For IT, remember, Hadoop by itself is not enough. Big Data Analytics requires to contextualize unstructured data from Hadoop using traditional RDMS database, data warehouse and finally put analytical models using, analytical language (like Oracle R Enterprise) and visualization tools. You need to integrate all these technologies and make it available to the team in order for them to make most efficient and effective use of data. (I also recommended reading: like Service Oriented Architecture ( SOA) it will take some time for us to fully realize the benefit and fully understand the power of Big Data.

Requirements, Process or Solution driven methodology for ERP implementation: What works best? 1

This post was co-authored by Christopher (Chris) Sharbaugh 

There are countless papers and articles on top risks for ERP implementation success.  There are an equal number of articles about implementation methodologies to mitigate those risks.

These many thoughts can be distilled into three major ERP implementation methodology categories:

  1. Requirements Based – This is the traditional approach to software development. Collect an extensive set of requirements that the system should be able to meet and then try to map those requirements to an ERP software package.
  2. Process Based – This is a modified requirements based approach. It advocates defining end-to-end processes that satisfy capabilities the organization is trying to deploy using an ERP.
  3. Solution Driven – This approach assumes the vendor’s software has best practices implemented and advocates applying them to satisfy capability requirements; any deviation from that is challenged.

In order to really determine what approach is most suited for the organization, lets start with establishing common understanding of few common terms:

      1. Methodology is defined in the Merriam dictionary as a body of methods, rules, and postulates employed by a discipline. Any Enterprise Resource Planning (ERP) implementation involves multiple disciplines. The extent of each discipline’s importance varies across the industry and across companies; e.g. the extent of organizational change required during the implementation of ERP varies across organizations.
      2. However, there are some paradigms that work best for delivering solutions quickly; they address the needs of the organization, and provide the foundation for users to deliver return-on investment.

To employ those paradigms, there are some important characteristics of ERP packages that you must remember:

  1. An ERP is the vendor’s culmination and implementation of an extensive number of companies’ and industries’ requirements.
  2. Those implemented requirements are packaged as a series of business capabilities and processes that must be integrated into the using company’s end-to-end processes.
  3. And lastly, ERP packages reflect the vendor’s interpretation of the most effective way to perform each business process. These best practices eases compliance with requirements such as Sarbanes-Oxley. They can also help compliance with de facto industry standards such as Electronic Fund Transfer (EFT). This is because the procedure can be easily codified and adapted across multiple businesses that share the same requirements.

At this point you could say, “There you have it; process based implementation is the way to go.”

“Not so fast,” others may respond, “those processes need the company’s data, business rules and employee roles sometimes at the task and activity level documented as explicit requirements to support the configuration.” 

Additionally, the touch-points or interface to the company’s end-to-end processes must be documented and governance-approved so that they don’t create a burden with interfaces.  It’s also vital to face the fact that no ERP will be a perfect fit for the business; there will be gaps that have to be accepted or filled with manual processes, bolt-on solutions, custom code, or SOA components.   The gaps must be defined at the requirements level to properly understand the business impact of filling them or not.

Now you’re thinking, “OK, now they are leading me to the solution driven approach.”

A solution driven approach is when the ERP team uses the actual software with the targeted users as an analysis and design tool.  It is a very powerful approach, especially when you consider users don’t have the time and organizations don’t have the money to perform extensive process modeling or requirements definition.   Additionally, when organizations invest in a process or requirements approach without referencing the ERP solution, more often than not they end-up with great and often expensive documentation of the as-is.  While this has merits, the impact is often more interfaces and extensions than less.  However, the solution driven approach will not support the first steps in the ERP journey: identifying the business problem; identifying ERP as the best solution; and selecting an ERP vendor that fits the company’s needs.

The bottom-line is that you need a hybrid methodology that is applied in the proper sequence to implement an ERP with higher velocity and at lower cost.  This fusion methodology is composed of:

  1. High-level Process Modeling
  2. Solution driven Process Decomposition
  3. Requirements driven Gap resolution

After the problem definition, you need to do some High-level process modeling in order to identify the ERP that is the best fit and select the appropriate vendor.   Process modeling includes scenario, capability, and architecture modeling.

  • Process models should not extend beyond the business and organizational flows with supporting data objects (e.g., invoice, customer, order, receipt, service request) and supporting systems.
  • Business scenarios are initial and high-level use cases.  Remember, the ERP has all the basics covered.  The scenarios should focus on the critical sub-processes or activities that make the company truly unique and are “make or break” for selecting using an ERP product (e.g., remote or mobile transactions, contracts, sales and inventory planning, pricing, invoicing, collections etc.).
  • The capability modeling should identify the must and should have features needed to support the processes and scenarios (e.g., RFID compatibility, Compliance, Multi-language, Automated approvals, Contracts templates, Serialization, Part numbering, # of users, locations, etc.).
  • The architecture model should identify the applications (purchasing, financial, inventory) that will be impacted or replaced by the solution and the enterprise solutions (e.g., security/identity, portal, messaging, ETL, Business Intelligence, encryption, etc.) that must be integrated with the ERP.

If you find the modeling team is at the activity, swim-lane, database table, or protocol level; stop: you have gone too far.    Additionally, the modeling will support investment prioritization, dependency identification, and team alignment for Agile development.

Once you have picked the vendor and modules, the solution driven approach will help bind the remaining processes and architecture decomposition to the ERP capabilities. It will also provide users with something they can see and touch while they define the detailed data, business rule, and role requirements at a level that can be configured by a technician.  Additionally, the team will be able to identify real process and capability gaps and their impacts to inform decisions about building Reports, Interfaces, Conversion, Extensions, Workflows, and Forms.

These gaps are where you can apply the traditional requirements driven or Agile approach; the team is essentially embarking on a custom development effort within the ERP project.  The identified gaps must be carefully evaluated and should be discouraged vigorously.  There are many tasks that will be more efficient with an ERP application and there will be some tasks that will be less efficient.  Keep in mind that any custom development in the ERP environment increases the possibility of a failed implementation. By some studies, 71% of total ERP failures are the result of extensive customizations and/or extensions under the guise of gap resolution.  You must document the requirements well and make sure that they are must have to successful business processes vs. just matching the way your organization/business is accustomed to doing or likes to do things.

An ERP is still the best alternative for replacing legacy applications and standardizing processes across the enterprise. It is important to apply a balanced approach and the right mix of methodology to be successful.

What’s the Future of ERP? 5

Is ERP Dead?

These days there is a lot to read on Cloud and Cloud Computing. I have a written few blogs on these same topics. In the frenzy of cloud computing (I do admit that the potential of cloud computing excites me very much), what do you think will happen to ERPs? I have had many discussions on the topic. It’s an ongoing debate with customers and system integrators alike. So I’d like to discuss my point of view here on my blog– and I certainly welcome your comments and feedback.

I recently visited museums in India. One of the museums featured India’s Industrial Revolution. It showcased how the country evolved as a spice exporter to a cotton producer and to a technology exporter. It’s an interesting history for sure. Now India is recognized for its technology knowledge base. The museum reminded me of one big fact. Still today, and most people don’t realize this, IT Services is less than 5% of India’s GDP. Agriculture followed by Services and Manufacturing continues to be the major portion of the Indian economy. Why is it important in this context? In today’s IT world, most magazines are full of cloud articles, blogs, presentations, conferences etc. In reality, according to some estimates, ERP Cloud applications (full or partial functionality) are ~$2 Billion. The total market size is over $150 Billion. If you include Supply Chain Management in the equation, the global market for ERP is even bigger. Contrast this with the adoption rate of Cloud Services for Email and Office tools. It is projected that Cloud will account for 40% market share in the next couple of years.

Why is this contrast between ERP adoption and other Cloud software?

Let’s trace the brief history of ERP (enterprise resource planning). There is a short article published in the Journal of Operations Management. I have tried to summarize it to jog our memories on why ERPs came about. In the early 1940s companies started using the calculating machine to automate some functions. When IBM started marketing mainframe machines for organizations, operators saw the value of the technology and some large organization stared to invest in it. Mainframes were used for specific functions and needed a lot of support and they created silos within organizations. For instance, there was a job to calculate payroll, there was a job to compute totals to be included in the financial book-keeping, but the two jobs didn’t necessarily talk to each other so humans had to intervene and made them match. This matching of jobs, however, caused inefficiency in operations as well as gross inaccuracies in reporting. Then someone thought it would be great idea to have systems talk to each other and automate some of these tasks. This started more specifically with Material Resource Planning (MRP) applications. This integration of business operations soon showed a benefit and then further “consumerization” of Information Technology allowed other companies (large and midsize) to start adopting it. Then companies like Intuit and NetSuite started to focus on small business to offer a similar benefit. Companies started to spend a substantive effort and resources to implement these business applications and standardized business processes. Salesforce and NetSuite changed the paradigm on how companies license the software. In early 2000, the Service Oriented Architecture (SOA) concept came about mainly to address the biggest issue with ERP. No single ERP could satisfy corporate requirements and it cost too much to integrate and keep systems fresh. SOA got a lot of press and was the talk of the town, but it never took off until just recently and (not surprisingly) it took off just after most large ERP vendors started supporting SOA natively.

Now, Cloud is the talk of the town. There is an increasing adoption of cloud services when it comes to infrastructure, but it’s still in its infancy. There is lot to learn. As it pertains to enterprise applications, there are many roadblocks. There is very little adoption of Cloud applications when it comes to enterprise business. The main reason for this lies in the history of ERP and how ERPs came about. ERP vendors like Oracle and SAP have plans to offer an ERP suite in the Cloud, but they are not in any hurry to do so for obvious reasons. There are niche players that offer specific applications where ERPs have gaps like WorkdayRightNow, etc. Integrating these individual applications into ERP is still an organization’s responsibility. Enterprises, however, will never go back to 1960-1970 where they have “siloed” applications and as a result still struggle to integrate them.


Cloud applications make business sense for those organizations that are not in the business of IT. Companies have been trying to set this up via outsourcing for some time, but it’s never actually relieved them of the burden of managing IT software and infrastructure. Cloud offers that promise. There is an opportunity for the System Integrator here to provide a platform that will give choices to the customer and allow them to integrate the various cloud applications from one or more vendors without organizations having to care about it. Both Cloud vendors and System Integrators need to figure this out together. If Cloud adoption is to really reach the enterprise in a meaningful way (outside of communication and messaging), this integration issue must be addressed. There needs to be a framework that can support integration of various platforms, technologies and applications with central management processes. It needs to be easy to understand and has to be secure.

For now, most organizations are still continuing to rely on ERPs. However, ERP vendors are now preparing for new ERP packages with a “Cloud” model by revamping their applications and licensing models to provide this option to their customers. ERPs are very much alive and will be here for some time to come. How it’s delivered to the customer will definitely change and System Integrators will have to play big role in the adoption of a Cloud model for ERPs.  This warrants a separate blog to discuss the role of System Integrators in our new Cloud economy. For now ERP is here to stay in some form and the role of System Integrator will still be a critical necessity for some time to come.