Oops! The input is malformed!
Originally published 3 October 2007
Since writing my last article, it has become apparent that some people in the workplace, IT included, have the impression that business intelligence (BI) and a data warehouse are the same thing! In my opinion, they are not. Business intelligence can come from any part of the business. Information can be used to make decisions (at any level) and can provide the business with intelligence.
Operational business intelligence and manufacturing go hand-in-hand, and manufacturing is probably the best channel to get the most out of the technologies that contribute to providing operational resources with the information they require to make informed decisions.
If we look at the value chain, most manufacturing companies would consist of the following departments; NPD, planning & scheduling, manufacturing, dispatch and distribution. I would suggest that all would benefit from having an operational BI architecture implemented – NPD might be the exception.
Figure 1: Operational Business Intelligence
Reporting can and does happen throughout the operational world. What makes it intelligent is the way the information is used throughout the value chain. As can be seen in Figure 1, reports are also run from the staging area in the data warehouse architecture. This is useful because it does provide more up-to-date information, but it does depend on how frequent the data is purged as some staging areas can be months old.
If we go through the integration flow in Figure 1 from beginning to end, it should be easy to follow the activities involved in operational business intelligence.
It should be noted that operational business intelligence can be as simple as reporting off transactional or operational systems, but it can be as complex as including BAM to complement the information provided to the user.
Unlike analytical business intelligence, where the typical method that is adopted for data integration is extract, transform and load (ETL), operational business intelligence uses a number of different methods. These are typically using a hub such as Biztalk server or Websphere Business Integration, EII tools or an ETL tool such as SQL Server Integration Services (SSIS). Any of these methods of integration can be used depending on the requirement.
ETL (Extract Transform and Load)
The question that always raises its head on projects in my workplace is whether to use MS Biztalk or MS SSIS for integration. When we decide on ETL, it is mainly because the requirement is either that a bulk update is required, there is no business process involvement or that a report needs to call an SSIS package that will provide a type of on-demand report from various operational data sources.
EII (Enterprise Information Integration)
When using EII, the information is sourced from a number of different operational data sources. A virtual business view is placed over those data stores and presented to the users. This leaves the underlying data in place, and it is not physically moved. This has obvious benefits: It uses demand-driven queries to operational systems, data warehouses (DW) and unstructured content. EII engines are read-only and are most useful when the source data requires little or no transformation. An ideal EII opportunity would be to use it to plug a gap where there are no operational applications or data warehouse from which to report.
EAI (Enterprise Application Integration) – Integration Hub
EAI is used to integrate applications across the business, allowing them to communicate and pass messages that are usually associated with a business process. Hubs can communicate with publishing and subscribing applications without knowing their formats. Hubs are very good at maintaining a loosely coupled integration design. EAI is usually employed for real-time processing, but it can also be used for master data synchronization. EAI is usually instantiated on an event basis, providing real-time process orchestration that can route information based on content values to the correct destination. This is known as content-based routing.
The three methods of integration described are not directly competing for the same work, but are more likely to complement each other in integration tasks across the enterprise.
If we look at the manufacturing value chain from an integration point of view, it becomes clear that many organisational departments operate in process silos. An example would be that planning & scheduling has no vision of the process or data that is used in distribution. Likewise it would be difficult to produce effective operational business intelligence sourcing the information from isolated parts of the business, unless some of the techniques described earlier were employed, such as EII. Figure 2 shows how manufacturing value chain integration can become disparate.
Figure 2: Operational Integration
The high level value chain process model in Figure 2 shows that there can be very little integration between departments. If there is any, then it tends to be a neighbour rather than a department farther along the chain. This lack of integration is typical of manufacturing companies that are struggling to benefit from consolidated information and process activity.
If a good integration strategy is adopted, then business benefits would ripple through the company, both at an operational level and at strategic level. Application integration between, say, manufacturing and distribution would provide distribution with a vision of what to expect off the production line, aiding them in better logistic management. Likewise, manufacturing could have visibility of whether the manufactured product has completed its journey and been distributed, rather than having become a loss along the way.
Of course, all this talk of integration helps provide integrated data to the business and ultimately produce reports that can direct business decisions.
Recent articles by Gary Holden