Business Process for BI Practitioners – A Primer

Business Intelligence has a fairly wide scope but at the fundamental level it is all about “Business Processes”. Let me explain a bit here.
BI, without the bells and whistles, is about understanding an organization’s business model, its business processes and ultimately find the reason (analytics) and way to optimize the processes. The actions are carried out based on informed judgments (aided by BI), to make the organization better in whatever endeavor it has set itself to accomplish.

Assuming that BI practitioners are convinced that understanding business process is critical to their work, let me delve a bit into the basics of it.

1) What is a business process? (As a side note, one of the best explanation for business models is given by Joan Magretta in her book ‘What Management Is”)

Business processes are set of activities involved within or outside an organization that work together to produce a business outcome for a customer or to an organization. The fact is that for an organization to function, there are many outcomes that are required to happen on a daily basis.

2) What are BPM Tools?

Business Process Management (BPM) tools are used to create an application that is helpful in designing business process models, process flow models, data flow models, rules and also helpful in simulating, optimizing, monitoring and maintaining various processes that occur within an organization.

3) The Mechanics of Business Modeling

Business Process Modeling is the first step, followed by Process Flow Modeling and Data Flow diagrams. All these 3 diagrams and associated documentation will help in getting the complete picture of an organization’s business processes. Brief explanation of these 3 types are given below:

a) In Business Process Modeling, an organization’s functions are represented by using boxes and arrows. Boxes represent activities and arrows represent information associated with that activity. Input, Output, Control and Mechanism are the 4 types of arrows. A box and arrows combination that describes one activity is called a context diagram and obviously there would be many context diagrams to explain all the activities within the enterprise.

b) Process Flow Modeling is a model that is a collection of several activities of the business. IDEF3 is the process description capture method and this workflow model explains the activity dependencies, timing, branching and merging of process flows, choice, looping and parallelism in much greater detail.

c) Data Flow Diagrams (DFD) are used to capture the flow of data between various business processes. DFD’s describe data sources, destinations, flows, data storage and transformations. DFDs contains five basic constructs namely: activities (processes), data flows, data stores, external references and physical resources.

Just like the data modeler goes thro’ conceptual, logical and physical modeling steps, a business process modeler creates the Business Process Models, Process Flow Models and Data Flow Diagrams to get a feel for the business processes that take place within an enterprise.

Thoughts for BI Practitioners:

1. Consider viewing BI from the point of optimizing business processes
2. Might be worthwhile to learn about Business Process Modeling, Process Flow Modeling and Data Flow Diagrams
3.  
4. Understand the working of BPM tools and its usage in the enterprise BI landscape
5. Beware of the acronym BPM. BPM is Business Process Management but can also be peddled as Business Performance Management.
6.  
7. My view is that Performance Management is at a higher level, in the sense, that it is a collective (synergistic) view of the performance of individual business processes. A strong performance management framework can help you drill-down to specific business processes that can be optimized to increase performance.

Analytics, its Evolution

What is ‘Analytics’ – A business intelligence application with ready to use components for data analysis, we also refer to it as ‘packaged analytics’. ‘Business Analytics’ refers to analytics applications that support analysis of data collected as part of a business process.

In similar lines we can define an analytics application that supports analysis of data collected as part of a ‘computer user’ daily activity as ‘Personal Analytics’.

Business systems evolved from the state of building custom applications to a state of configurable generic Enterprise Resource Planning (ERP) systems. Now we have configurable generic business intelligence applications called ‘Business Analytics’ which have evolved from the state of building custom business intelligence applications.

The ERP systems are designed to collect the business data where as the Business Analytics systems are designed to analyze the collated business data, so one of the key sources for a Business Analytics application is an ERP system. Data analysis is a next logical step after data collection, the ERP vendors like Oracle, SAP, Microsoft got delayed in addressing this specific requirement of data analysis. In the last two years we have seen some finer business intelligence products being acquired by the ERP vendors. Clearly the customers who are on ERP products would get a better platform that can talk to their ERP applications for data analysis.

It’s a reality that not many companies, at least the larger (>USD 500million) companies would not run their entire business in one ERP system. Consolidating all applications to one single ERP platform will not happen immediately, multiple ERP and custom applications would get added if the company grows through acquisitions, hence existence of multiple transaction systems cannot be avoided. The number of customers embracing packaged analytics from the ERP vendors will increase as the flexibility of the business analytics applications from the ERP vendors matures to accept data from other outside applications.

Logical Data Model to Packaged Reports

The business analytics applications grew step by step as following

• 1. Logical data model – as a first step towards the formation of packaged analytics, companies like IBM, Teradata provided industry specific logical data models (LDM) to help customers build their enterprise data warehouse. The LDM was based on the business process and provided the required jumpstart to enable the integration of data from multiple source systems effectively. We also have certain industry endorsed LDMs like Supply-Chain Operations Reference-model (SCOR), Public Petroleum Data Model(PPDM
• 2. Metrics definition – LDMs led to the next step of defining metrics to measure the performance of the business process. The required data for the metrics that were specific to a business process were extracted (virtually/physically) into data marts as analytic data models in a fact-dimension data model
• 3. Semantic Layers – the next step was the creation of semantic layer over the data mart to enable adhoc querying and report generation
• 4. Reports and Dashboards – then we had set of reports and dashboards delivered over the semantic layer

Still the packaged analytics are positioned as a data mart application addressing specific business process like HR or Customer Relationship, unlike ERP systems which addresses complete end to end business process of an organization…there is still more time to go for an Enterprise Analytics Application to be established.

Read More About  Analytics and its Evolution

Informatica PowerCenter 8x Key Concepts – 5

5. Repository Service

As we already discussed about metadata repository, now we discuss a separate,multi-threaded process that retrieves, inserts and updates metadata in the repository database tables, it is Repository Service.
Repository service manages connections to the PowerCenter repository from PowerCenter client applications like Desinger, Workflow Manager, Monitor, Repository manager, console and integration service. Repository service is responsible for ensuring the consistency of metdata in the repository.

Creation & Properties:

Use the PowerCenter Administration Console Navigator window to create a Repository Service. The properties needed to create are,

Service Name – name of the service like rep_SalesPerformanceDev

Location – Domain and folder where the service is created

License – license service name

Node, Primary Node & Backup Nodes – Node on which the service process runs

CodePage – The Repository Service uses the character set encoded in the repository code page when writing data to the repository

Database type & details – Type of database, username, pwd, connect string and tablespacename

The above properties are sufficient to create a repository service, however we can take a look at following features which are important for better performance and maintenance.

General Properties

> OperatingMode: Values are Normal and Exclusive. Use Exclusive mode to perform administrative tasks like enabling version control or promoting local to global repository

> EnableVersionControl: Creates a versioned repository

Node Assignments: “High availability option” is licensed feature which allows us to choose Primary & Backup nodes for continuous running of the repository service. Under normal licenses would see only only Node to select from

Database Properties

> DatabaseArrayOperationSize: Number of rows to fetch each time an array database operation is issued, such as insert or fetch. Default is 100

> DatabasePoolSize:Maximum number of connections to the repository database that the Repository Service can establish. If the Repository Service tries to establish more connections than specified for DatabasePoolSize, it times out the connection attempt after the number of seconds specified for DatabaseConnectionTimeout

Advanced Properties

> CommentsRequiredFor Checkin: Requires users to add comments when checking in repository objects.

> Error Severity Level: Level of error messages written to the Repository Service log. Specify one of the following message levels: Fatal, Error, Warning, Info, Trace & Debug

> EnableRepAgentCaching:Enables repository agent caching. Repository agent caching provides optimal performance of the repository when you run workflows. When you enable repository agent caching, the Repository Service process caches metadata requested by the Integration Service. Default is Yes.

> RACacheCapacity:Number of objects that the cache can contain when repository agent caching is enabled. You can increase the number of objects if there is available memory on the machine running the Repository Service process. The value must be between 100 and 10,000,000,000. Default is 10,000

> AllowWritesWithRACaching: Allows you to modify metadata in the repository when repository agent caching is enabled. When you allow writes, the Repository Service process flushes the cache each time you save metadata through the PowerCenter Client tools. You might want to disable writes to improve performance in a production environment where the Integration Service makes all changes to repository metadata. Default is Yes.

Environment Variables

The database client code page on a node is usually controlled by an environment variable. For example, Oracle uses NLS_LANG, and IBM DB2 uses DB2CODEPAGE. All Integration Services and Repository Services that run on this node use the same environment variable. You can configure a Repository Service process to use a different value for the database client code page environment variable than the value set for the node.

You might want to configure the code page environment variable for a Repository Service process when the Repository Service process requires a different database client code page than the Integration Service process running on the same node.

For example, the Integration Service reads from and writes to databases using the UTF-8 code page. The Integration Service requires that the code page environment variable be set to UTF-8. However, you have a Shift-JIS repository that requires that the code page environment variable be set to Shift-JIS. Set the environment variable on the node to UTF-8. Then add the environment variable to the Repository Service process properties and set the value to Shift-JIS.

Read More about Informatica PowerCenter 8x 

What is “Safe to Bet On” in Business Intelligence?

While the phrase “Safe to Bet On” is an oxymoron of sorts, it is that time of the year where we first look at the past, derive some insights and look forward to what the future has in store for us. I have no doubts that 2009 will be doubly interesting for BI practitioners as compared to 2008.
Having said that, I decided to do a bit of introspection to figure out what skills (can also be read as competencies) should I be looking at to stay relevant in the Business Intelligence world far into the future, say at 2020. Hopefully that resonates with some of you.

Let me first try and get down to defining the skills required for Business Intelligence and Analytics. The trick here is to stay “high-level” as any BI person will acknowledge the fact that one we get down to look at the trees (rather than the forest), the sheer number of skills required for enterprise level BI can get daunting

Taking inspiration from the fact that any business can be condensed into 2 basic functions, viz. Making & Selling, I propose that there are 3 key skills that make for successful BI

Skill 1 – Business Process Understanding: If you are a core industry expert and can still talk about multi-dimensional expressions, that’s great! But most BI practitioners have their formative years rooted on the technology side and have implemented solutions across industries. The ability to understand the value-chain of any industry, map out business processes, identify optimization areas, translating IT benefits to business benefits are the key sub-skills in this area.

Skill 2 – Architecting BI Solutions: This skill is all about answering the question of “What is the blue-print” for building the Business Intelligence Landscape in the organization. Traditionally, we have built data warehouses & data marts either top-down or bottom-up, integrated data from multiple sources into physical repositories, modeled them dimensionally, provided ad-hoc query capability and we are done! – NOT ANYMORE. With ever increasing data volumes, real-time requirements imposed by Operational BI, increased sophistication for end-user analytics, the clamor for leveraging unstructured data on one hand and the advent of On-Demand Analytics, Data Mashups, Data Warehouse appliances, etc., there is no single best way to build a BI infrastructure. So the answer to “What is the blue-print?” is “It depends”. It depends on many factors (some of which are known today and many which aren’t) and the person / organization who appreciates these factors and finds the best fit to a particular situation is bound to succeed.

Skill 3 – BI Tools Expertise: Once a blue-print is defined and optimization areas identified, we need the tools that can turn those ideas into reality. BI practitioners have many tools at their disposal straddling the entire spectrum with excel spreadsheets at one end to high-end data mining tools at the other extreme. If you bring in the ETL & data modeling tools, the number of industry-strength tools gets into the 50s and beyond. With convergence of web technologies, XML, etc. into mainstream BI, it probably makes sense to simplify and say “Anything you imagine can be done with appropriate BI tools”. “Appropriate” is the key word here and it takes good amount of experience (and some luck) to get it right.

In essence, my prescription for BI practitioners to stay relevant in 2020 is to be aware of developments on these 3 major areas, develop specific techniques / sub-skills for each one of them and more importantly respect & collaborate with the BI practitioner in the next cubicle (which translates to anywhere across the globe in this flat world) for he/she would bring in complementary strengths.

Read More About  Safe to Bet On