To Celebrate 500th Blog: Is Life a Serendipity

Life is like a Box of Chocolate with a Cup of Tea.

Life is a mystery; life is a gift; life is a beauty, life is a hard journey with soft touch; life is a serendipity; some life are straight; others are curvilinear; but every life is special, unique, and precious; every life has god complexity in it and abstraction of universe; what’re those interesting life metaphors? And is life a metaphor for all things?

1.    Life is like a Seed

From a small seed a mighty trunk may grow.  Aeschylus

Life is like a seed, inside each seed, there is an unseen potential, unleashed energy; unimaginable colors and uncompromised substances; a big strong tree is metaphorically inside this tiny seed, but it will never grow unless planted and nourished. Life is like four seasons, there’s time to sow, time to grow, time to harvest and time to enjoy. It is the awareness of unfulfilled potential which gives a person the feeling that he or she has a destiny, there’re inner fulfillment includes many factors such as intellectual satisfaction, purpose, curiosity, inspiration, insight and discovery, etc. ideally , the seeds grow into what they suppose to be, the transformation of living beings; the maturity of life and the miracle of nature.

2.    Life is like Photography

“Squeeze an orange-you get orange juice.  Squeeze a lemon- you get lemon juice. When a human is squeezed, you get what is inside- positive or negative.”   -Jack Kinder

One needs to develop positive from negative. Life is like photography. Focus is an ingredient to have a good shot. Life is like a camera. Just focus on what’s important, capture the positive moment, develop from the negatives, overcome barriers and bias, breakthrough ceilings, mind gaps, and make difference;  if things don’t turn out – take another shot. Beyond photography, life is like a book with well-selected pictures, you are the author and everyday is a new page.

3.    Life is like a White Canvas

Remember when life's path is steep to keep your mind even. --Horace  

Life is like a canvas, the colors we are going to use are up to our own choices: be it blue, yellow, purple, or silver. It reflects the color of your character and sharpness of your eyes, the breadth of your heart and depth of your soul. You need to connect the dots or paint the numbers; you need to measure the sizes or manage the shapes; it’s the art to be colorful, but not flashy; original but not primitive; elegant but not complex; simple but not tedious; classic but not out of date. Life is also like a jigsaw puzzle, but you don't have the picture on the front of the box to know what it's supposed to look like. Sometimes, you're not even sure if you've got all the pieces. It takes imagination and hard working to craft it.

4.    Life is like Treasure Hunting

"All outside greatness is merely an incidental reflection of the inside." -Ralph Parlette

Perhaps there’re no wonders when walking on the big road; and the hidden treasure of life can only be discovered when you take serendipitous path; or the rare-traveled trail; there’s ‘get lost’ –disappointing moment, also some major turning points; those defining moments will shape the life destiny. Either pursuing intellectual satisfaction or universal happiness; physical strength or spiritual maturity, peace or wisdom, life is the treasure-hunting journey which can take different path and enjoy it.

5. Life like a box of chocolates with a Cup of Tea

Life is a succession of lessons which must be lived to be understood -Helen Keller

Life is like a box of chocolates, you'll never know what you're going to get. And life is also like to have a cup of tea, taste bitter but smell great; Life is like to have ice cream, cold but fit for need when timing is right; it takes courage, curiosity, openness, wildness, patience, perseverance, concentration and appreciation to really enjoy it. 

More collective Metaphors about Life:

• Life is like a Running River. With all its bends and rapid falls, one must follow the right path or else you'll lose your way. Perhaps it’s the right destiny to merge into the sea.

• Life is like riding an elevator. It has a lot of ups and downs and someone is always pushing your buttons: there’re hot button matters; the wrong button get pushed once a while;

• Life is a roller coaster. You can either scream every time you hit a bump or you can throw your hands up in the air or enjoy it.

• Life is like expressway (wish).The only difference is that there are potholes and humps along the way. But if you were ready and prepared just right, you'll have a smooth ride ahead.

• Life is like a bagel. It's delicious when it's fresh and warm, but often it's just hard. The hole in the middle is its great mystery, and yet it wouldn't be a bagel without it. Life is like eating grapefruit. First you have to break through the skin; then it takes a couple of bites to get used to the taste, and just as you begin to enjoy it, it squirts you in the eye.

• Life is a challenge - meet it. Life is a song - sing it. Life is a game - play it. Life is a dream - realize it. Life is a sacrifice - offer it. Life is love - enjoy it. -Sai Baba 

Life is a serendipitous journey, have a plan, but not over-plan it; take the nature path, keep the original design; let it grow & mature; keep its full theme and color; cognizant of ups & downs, capture the insight of its meaning; and feel humbled, as life are bits and bytes of whole Universe, add some colors and make certain signals, every bit of positive influence count…

Read More

CIO as Chief Integration Officer: How to identify Building Blocks in an IT project?

A key foundation would be to approach the project from the perspective of being a business project, not an IT project.  

CIO continually advocates - there are no IT projects, only business projects; and, there is no IT and business, we are all part of "the business". However, IT projects statistically have much higher failure rate than another type of business project due to the complex nature. 

Hence, in order to manage successful IT projects, how to identify building blocks in an IT project, what could be the possible Architecture building blocks and solution building blocks of an IT project spanning on many teams, processes, custom development and third party software?

A key foundation would be to approach the project from the perspective of being a business project, not an IT project.  Any project must attend to the business use, the business change necessary for the effective use and for the realization of the business value, so the project is a business project because it effects change in business behavior associated with the delivery of IT output. Hence, the delivery of the IT output is only half the story. Organizations are discovering that by positioning projects as business change projects which create demands for systems change, much better outcomes are achieved.

Capabilities are good starting points. Architecture Building Blocks map decently to capabilities.
a) Identify Business Capabilities: Create a business architecture for the enterprise which would have identified business capabilities as primary building blocks for the enterprise;
b) Identify Technical Capabilities: Created a technical architecture for the enterprise which would have identified the technical capabilities upon which these business capabilities will be reliant;
c) Create a business capability heat-map and related technical capability heat-map
d) Create a business project to improve a nominated business capability and associated technical capabilities.
e) Create a project brief that described objectives, scope, business outcomes, business and technical capabilities within scope, approach, costs, time frames, risks, etc as the initial basis for launching the project.

With a strong EA focus and good project management practices, IT project can be managed as the business project with real business value, enabled by a combination of IT and non-IT solutions. Proceed with typical business analysis, creating:

a) Business process requirements
b) Information requirements
c) System requirements
d) People requirements
e) Non-functional requirements

An Architecture Building Block (ABB) typically represents a required capability, while Solution Building Blocks represent components that implement the required capability. The solution building block referred to maps closely to the "Application Map". What needs be further drilled down on the solution map to depict the key interactions for the Application map to be readable.

The Architecture block could typically cover the overall IT landscape and needs to be represented using a few separate artifacts like a) Business Services view; b) Technology view. While IT landscape would have to iterate through some of the models below: a) Process/Capability model of the business; b) Application Map (for the whole/part of the IT/Process/Capability)

Project/portfolio Management/Governance Blocks: There are two interdependent blocks : Project Management and Change/Governance Management. There are three levels of management disciplines: Project management (to ensure doing things right in an efficient way); Program management (Realizing benefit, through identifying interdependence of a series of inter-related projects; and Portfolio management (doing the right things for effectiveness). Navigate Project Blocks via 5W+1H:
- Why: the user case to justify logic reasons for project initiative, sponsorship, pros & cons.
- What: The customer requirement collection, the scope, specification of the project.
- How: The implementation phases, the business processes & capabilities to realize it.                       

 - Who: People are still weakest link many times, talent management.

- When/Where: The Road Map, Milestone setting, Metrics, KPIs.

Read More

EA as Communication Glue

Abstraction and agreement is the way forward, not elaboration and disagreement.

Enterprise Architecture may be a skill in documenting what others know but the EA must learn where the architecture can help improve weaknesses and take advantage of organizational strengths. The methods and techniques used to document and manage the architecture are important but building understanding and communicating among the many functions becomes the most significant contribution for an EA. To put simply, instead of being a guru, EA needs to become a communication glue,  to bridge the silo and mind the difference.

1. EA#1 value - communication through coordination, and the resultant change. If the scope and content of business initiatives change as a result of EA's intervention in bringing coordinated efforts, aligned with strategy, then there should be immediate value. 

2. EA can become one of the communication tools at the senior leadership team, to keep every party on the same page. Or, while the 'C' level may act on recommendations coming from an architecture initiative, they don't really use the architecture itself. The recommendations could just have easily come from some other processes.  

3. The Enterprise Architecture is used to make strategic decisions for driving the future of the company. The data provided in the architecture provides guidance/direction on what steps need to be taken by the board to reach their strategic goals for the company. EA would result in decreased diversity of projects, or at least projects that focus on satisfying business initiatives linked to strategy 

4. This architectural description may contain multiple views in order to convey the key concepts: It typically requires a good bit of accompanying text to describe the key concepts and processes to teams responsible for implementation. Maybe one of the underlying values of architecture is just having the holistic view available... and then be able to shape strategy; to get the most profit out of the way. USE the architecture to figure out the best way to make the right choices 

5. In order to communicate better, what one would concentrate to communicate FIRST or MOST. Communicate FIRST- the EA implementation plan to the executive sponsor and other stakeholders in order to gain buy-in and support. These pre-documentation activities are important to ensure that the EA program has clear goals, remains focused, and is accepted throughout the enterprise. Communication MOST – EA practices require a holistic viewpoint and cross-functional support. The architecture also helps to communicate what needs to be done down the line to the various functional domain managers responsible for implementing those steps coming from the board. 

6. EA Communication Theme: Abstraction and agreement is the way forward, not elaboration and disagreement. Agreements must be first obtained for context and problem definition. Then one may look for the right level of abstraction, the one that sets apart the relevant features and clarify the options at hand. Finally, everyone may agree or disagree with. Abstract means, take the thing under discussion to a higher level of abstraction (by Omission, Composition, Generalization or Idealization). Abstraction enables agreement, and empathic elaboration will further enforce the agreement.  

7. Respect is the basis for any effective two-way communication. Respect does not require an arbiter - it requires a different mindset and different behavior. If I am respectful of your contributions, it is to recognize the value that they offer, to genuinely attempt to adjust my own position or mental models to incorporate and reflect the additional value or insight you are offering, Respect will seek to avoid argument, respect will take on a mode of listening and reflective-ness, seeking to express the new or modified way that might reflect the insights of the various contributions. It adopts more of a win/win rather than lose/lose or adversarial position,  and to move to a position which might work for more people rather than less people, whilst at the same time not losing the core value and integrity that might have attached to the base proposal. RESPECT means

         R-Reliable
         E: Effort
         S: Sense
         P: Polite
         E: Execution
        C: Communication
        T: Trustworthy

Read more about EA's Role:
EA as Vista Point Viewfinder

EA as Communication Glue

EA as Strategic Planning Tool

EA as Silo Integrator

EA as Problems Solver

EA as Governance Champion

EA as Complexity Master
EA as Process Conductor
EA as Capability Producer
EA as Change Agent
EA as Strategy Steward
EA as Innovation Enthusiast 

Read More

CIO as Chief Improvement Officer

"Continual improvement" is IT mantra in digital era.

The “I” in the CIO title is full of imagination; the "Chief Improvement Officer" is a right fit for the modern CIO role. CIOs need to have unique business insight, technological vision to understand the business not only from the inside-out viewpoint but through outside-in customer’s lens. With that knowledge, CIOs can drive innovation to improve the hard business process and soft organizational culture by implementing the technical solution and improve IT and overall business agility and maturity.

CIOs should have "know-how" attitude about the business and co-develop strategy: They are able to demonstrate the full reasoning behind the proposal, shift to proactive mode smoothly; that needs a strong team, a full understanding of the business and how IT underpins all elements of it. CIOs should also make influence and improvement upon soft business factors such as culture as the CIO is at the right position to well align people, process, and technology seamlessly and link hard process and soft culture inherently, to shape the culture of learning and analytics, to improve organization’s information maturity and innovation capabilities.

Progressive CIOs should, in fact, take the lead in introducing process management into the company: Since CIOs tend to have a process-oriented perspective, they should also seize the opportunity to take a fresh look at the processes through which IT creates value for its customers—from system development and user support to operations—and subject them to the same rigorous management that's being applied to processes in the core of the business. Every organization needs to drive continual improvement in order to meet their objectives and stay competitive. There are some CIOs with a growth mindset continually looking to optimize Revenue, Profits and Customer Satisfaction. There are also CIOs who are risk-averse and don't want to take on initiatives that will create more work or issues for them, with “don't fix it until it breaks” mode. An effective CIO’s job is to improve operations to reduce the burden on the company while trying to stay current with ever-changing technologies. That includes reducing costs, improving systems, streamlining processes and providing continually expanding services:
- People and process (skills, org, workflow, efficiency, and process)
-Technologies/assets already owned need to be centralized, moved out, re-allocated, updated, or replaced if needed to optimize "people and process". Also includes a broad range of monitoring, performance measurement, performance reporting, functional failover schemes, etc.
- IT Management: Efficiency, skills alignment, talent methods, performance mgmt, etc.

An effective CIO should lead by leveraging metrics that substantiate the ROI: CIOs need to keep a measure and periodicity at which the measure is reviewed against setting targets. Then ensure IT raises the bar on a continual basis to ensure the stakeholders get a real picture of how well the optimization efforts are bearing desired results. CIOs should have governance systems in place that drive continual improvement. Senior managers need to own process within their area with the CIO office facilitating the end to end business process mapping, assisting in defining appropriate owners and handoff points across the business. Without a full understanding of upstream and downstream impacts, inefficiencies across operational silos won't be addressed.

"Continual improvement" is the IT mantra in the digital era; there is never an "enough" to optimizing operations. Further, complacency is maligned when it comes to optimizing operations both in terms of cost and efficiency. However, the optimization of technology should not be the be-all and end-all at the expense of the health of the overall organization. Setting realistic priorities that are in line with organizational objectives might mean that optimization, while still a good thing, might not be what gets the focus in the short-range. And "CIO as Chief Improvement Officer" is one of the most appropriate titles to be a digital IT leader.

Read More about magic "I" in CIOs:

CIO as Chief Inspiration Officer

CIO as Chief Improvement Officer

CIO as Chief Improvement Officer II

CIO as Chief Improvement Officer III

CIO as Chief Insight Officer

CIO as Chief Influence Officer

CIO as Chief Innovation Officer

CIO as Chief Intrapreneur Officer

CIO as Chief Integration Officer

CIO as Chief Intelligence Officer

CIO as Chief Information Officer

CIO as Chief Investigation Officer

CIO as Chief Investment Officer

CIO as Chief Interpretation Officer

CIO as Chief Inclusiveness Officer

CIO as Chief Imagination Officer

CIO as Change Agent

CIO as Governance Champion

Read More

CIO’s Journey: From Crafing Strategy to Taking Roadmap

 IT roadmap is a playbook every IT executive should have or build whether requested or not.

If the strategy is a“blue book” to envision the future of organization; then, the roadmap is more as a playbook to describe in detail upon how to get there. IT road map is a chronological plan designed to blaze a clear path for IT investments and to ensure that the company gains the set of capabilities, expressed in the form of architecture “blueprint” & ‘strategy bluebook”. 

IT roadmap is a playbook every IT executive should have or build whether requested or not, as it is essential to the CIO doing his/her job correctly and being able to act when working with the business. But how should CIOs develop an effective and realistic IT roadmap? What might be some initial questions that one should ask?

Start with series of questions: (1) Why do you think you need an IT Roadmap? (2) Does the business see a value in such an effort? (3) Does IT see a value in such an effort? 4) What are some of the initial steps one should take? A good place to start asking questions is those that elicit where/what you are today (current state) and what does "the end of the road" also known as a target state. Be able to communicate the roadmap and make sure it is flexible and evolves with the company

IT strategic planning: The next step must be to understand the business strategy/roadmap/ culture, within that context, you develop IT strategic planning (bluebook of direction) and IT roadmap (playbook with milestones), you need to know where they are today and get a perspective on how IT is supporting the business today. Once you know that current state (the starting point) for both the business and IT and how well they interrelate and get a vision for the business, then you can begin to put a vision together for IT. The last step will be to determine how you get from current state to the vision state in detail (the roadmap). A key ingredient will be the expectations and requirements from business management on how they expect IT to contribute to the overall business.
Understand your current state. This includes:
- an inventory of the services IT currently provides to the business - technology assets used to provide/operate/support those service - people assets used to provide/operate/support those services - the costs of the assets and services necessary to bring the internal IT services to the business - current IT project portfolio (new/upgraded services already planned and services to be retired) - current business strategy - what new technologies/service are emerging in the market that the business and/or IT thinks would benefit the current business strategy - what opportunities are available to improve/consolidate/retire services

Define Future State: When building the future state, make sure that you break it down into looking at the ideal future first, followed by the real future and then finally the practical one
- what is the future business strategy? (2~3years).
- what services will IT need to provide to support the future business strategy (what will be new/changed and what will be retired)
- what technology assets are currently on the market and/or emerging that will be necessary to provide those services
- what people assets will be necessary to provide those services

Develop an IT Roadmap from Current state to Future State:
- it should overlay squarely on the business strategy
- it should be no longer out than the business strategy and no longer than 18/24 months
- it should include a high-level IT project portfolio to accomplish the transition of IT services in terms of technology, people, and secondary services
- it should provide financial assets required for the transition

Develop the business plan and cases: Roadmaps can sometimes be just technology transitions, but usually have social and organizational components of change. Develop a business plan for the IT strategic roadmap; develop the business case for the roadmap; begin to socialize with business team and management to gain support.
- Begin with the current application and infrastructure portfolio. Application portfolio is probably easier to obtain.
-Next Steps: outline the major business processes at the highest level.
-Map the applications to the processes -- by location/region/etc.
-Begin the process of evaluating the current application portfolio for 'the keepers' -apps that can form the foundation for the future
-Create your sunset plan for duplicate applications Are there multiple applications providing the same service? Look to re-use and integrate wherever possible.
- Pay specific attention to integration, quality, standards, regulations, etc.

Stay close to the business throughout the entire process: Get some great business people in the company to help you both as a participant and also as a reviewer and find the "influencers" in each business area to help criticize and make suggestions. Understand the business that the company is in and its competitors to look at how other companies are doing the same processes or functions. Talk to other companies or use your other resources.

Understand business processes: Always look at the business processes and data as well as the current business functions to make sure that you truly understand how the business does its job- not just the job they do. This will help you understand why potential current solutions are the way they are and also help you look for possible re-engineering efforts that the business will want or is doing that you will have to handle in the future state. It's much easier if there is an Asset Management system that contains the applications and infrastructure -- and, there are tools that will use that information to support the development and representation of the end state.

Put together a priority scheme such as A - Must have, B - Need, C- Want or Like to have. Validate this as part of both the current and future state. Make sure the recommended roadmap is staged with alternatives and complete high-level resource and budgets included. You have to have a prioritized staged approach that lets the company get the biggest bang for the buck as early as possible versus requiring everything to be completed before any benefit.

Detail Scenario to develop IT Roadmap:

1)     Identify key people in the business at all level, who use the system to meet the business needs in terms of strategy execution, information analysis, record keeping etc. 

2)     Conduct a survey - Ask them to write about their imagination of an Ideal IT system to meet their needs, their expectations of IT to help in business along with timelines, the timelines and their contributions to meet their own expectations.

3)     Understand the business strategy (If exists in black and white) or use the one that is most commonly perceived by the key personnel in the business.

4)     Publish the consolidated list of your findings and apply feedback.

5)     Understand the organization culture and how IT savvy it is.

6)     Understand and do an inventory of current IT department in infrastructure, skills, personnel, capabilities, ambitions & aspirations. 

7)     Using the above data, define” to be” state at the end of the time period that you are developing the roadmap for. Usually 3 to 5 years

8)     Define more than one ways of achieving the goal 

9)     For each approach, estimate costs, resources required, timelines, risks involved, and trends 

10) Conduct organizational level briefing and choose most suitable and acceptable approach 

11) Break it down into several stages. Each stage being a point where in business gets the benefit of the activities so far or taken up the activities so far to form a stepping stone for the big step. 

12) Attach timelines, interim goals, assumptions, business units’ support needs and implementation plans. 

13) Get acceptance from the senior management for the costs, timelines, budget allocation, resource requirements, training, and freeze the road map and publish it.

Read More

CIO as Strategist: What’s in your Strategic Planning

IT strategy is satisfied just through the WHAT-HOW transitions from corporate strategy. 

The whole purpose of the strategy of any kind is to envision the future success, then figure out how to execute to that end. IT strategy should always be an integral component of corporate strategy. What would be a good content for IT strategic plan? Should CIOs simply develop IT plans to support existing business strategy or should they, in addition, be working in the business to identify areas where IT can make a positive contribution to the bottom line and top line growth?

IT Strategy needs to closely link to the Business Strategy: Set the Business strategy as the basis. Then carry-out an As-is assessment of the IT environment and create your IT strategy accordingly. Take care to not distance yourself from directly linked business value. One of the key ways that a CIO can become a business leader (and not just a technology manager) is to become connected at the hip with the business. By understanding WHAT organization is going to do to enable each and every business initiative defined in corporate strategy (assuming there is strategy efforts defined, not just a 3-5 year financial plan). Then within the IT ranks, CIOs can take each of these WHATs, and figure out the HOW that will implement and execute the strategy effectively.  

IT strategy is satisfied just through the WHAT-HOW transitions from corporate strategy. The IT strategic plan must be closely tied to that of the business.  Strategic planning identifies where the organization wants to be at some point in the future and how it is going to get there. The "strategic" part of this planning process is the continual attention to current changes in the organization and its external environment, and how this affects the future of the organization. The WHY (strategy) is potentially satisfied by a set of WHATs (business initiatives) that are executed by a set of HOWs (project efforts). Projects have elements in multiple functional organizations, including IT.

The strategy must be crafted in such a way that it matches (or enhances) the maturity level of the organization. It must also be compelling so that it does not simply sit on the shelf after it is developed. a) Taking a wide look around at what's going on outside the organization and how it might affect the organization (an environmental scan), and identifying opportunities and threats b) Taking a hard look at what's going on inside the organization, including its strengths and weaknesses (perhaps doing a SWOT analysis) c) Establishing statements of mission, vision and values (some prefer to do that as the first step in planning) d) Establishing goals to accomplish over the next (usually) three years or so, as a result of what's going on inside and outside the organization e) Identifying how those goals will be reached (strategies, objectives, responsibilities, and timelines)

IT strategic plan needs to be a community effort, not something the IT team does alone in a corner. You need to talk to the business people, find out what their key initiatives are, and discuss how IT can facilitate, enable or support their initiatives. Talk about shared goals, and shared risks. Discuss timelines and milestones. Identify metrics and KPIs that will be shared across teams, and talk about funding and resource commitments.
1) Understand the business goals.
2) Understand the outcome of the goals.
3) Understand the business roadmap.
4) Understand the functions of the various departments.
5) Understand the kind of information required by the decision makers
6) Understand the kind of information required by the customers
7) Understand the products and services of the business
8) Find the gaps in all of the above and fill them.

The IT plan must be ‘driven’ by the business strategic plan for the same time frame. The business plan determines the IT plan. A set of corporate strategies (there is never one, but seldom more than 5-10), each has a set of business initiatives identified as potential methods of executing that strategy. Each strategy should have a set of metrics associated with measuring, at the very least, the direction of change, if not the magnitude. Each business initiative has a set of required project activities. HOW is IT going to not only enable those projects < initiatives < strategy to work, but also HOW is IT going to create more value than what would be possible with IT as a basic service organization?  

There are so many ways in which you need to cascade strategy down to the tactical, policy and project levels.IT Strategy has to take into account current infrastructure and new business objectives that may (should) require the use of technology. The detailed elements that flesh this out depend on the business focus area; although a summary set of slides demonstrating interim architectures together with the business features that have become available is the backbone. Backing this up with descriptions of the projects, portfolio cost, benefit and outline approach, technology, aggregate risk, dependencies and organizational structure changes

The planning process is at least as important as the planning document itself. The planning process is never "done" -- the planning process is a continuous cycle that's part of the management process itself. There are a set of goals associated with each strategy - typically a balanced scorecard view - and all strategic execution subordinate functions, contribute to those goals. Making strategic planning agile, dynamic to embrace the change, enforce iterative communication and continuous improvement

Read More

Process Analysis vs. Process Design vs. Process Modeling

 It's about execution! Making your processes do what they promise.

BPM is at CIO’s priority agenda in many organizations. The advent of information technology enabled tools and suites for business process management has created a hot bed of activity in which standards are still evolving and the underlying technologies still maturing. 

Clarifying certain fundamental concept such as what’re differences between process analyses. vs. process design vs. process modeling, is not only necessary but important as these words mean same to certain people and different to others. Here are some collective perspectives.

1.     Process Analysis is Conceptual, while Process Design is Logical: A first distinction should be drawn between process analysis and process design. Analysis is conceptual (what is done, what is needed) (describes the problem) and what can be done for existing "as-is" processes (what is done) or for future "to-be" processes (what is needed). Process design is logical (how it is or will be done) (describes a solution) - It's more detailed than process analysis and is constrained by the requirements that come out of analysis. Design is usually only done on "to be" future processes because the existing "as-is" processes are already designed. 

2.     Process modeling as a part of the overall design phase which aids in process analysis. Another scenario could be where an organization has a method of doing things that are not standardized or consistent. The ultimate goals of the organization are perhaps being achieved, but in a very haphazard way and with no certainty. In this case the analyst will be required to design a new process starting off with the modeling phase. So in a nutshell Process Design may be described as the larger activity of creating new processes or improving on existing ones, while Process Modeling may be described as a part of the overall design phase which aids in process analysis.

3.     Process Modeling is one of Process Design Tools: Process design is when an analyst looks at how things are currently being done (as-is) in an organization and creates better processes. In designing the process the analyst would need to rely on a several tools and skills. One of them would be Process Modeling. This is where the analyst examines the “as-is” by making a graphical representation of the model using illustrations. After “drawing” out the process, the analyst would find it a lot easier to measure the relevant process metrics.

4.     Both process analysis and process designs are done using process documentation. This documentation should contain text, diagrams and numbers. The creation of this process documentation is called process modeling. The resulting process document contains "process models". But a process model is not just the diagram. A process model also contains the text and numbers.

5.     Designing and modeling are the two sides that make a bit of metal a coin. From a closed loop system perspective,  if a process exists, the process designers create a model of it and measure the outputs; if it produces the desired results, wonderful, if not, then use the model to identify the process pieces most likely to be responsible and re-design them. If no process exists, or, if it is incapable of delivering measurable results, then process designers start with a design, model it, measure it, and seek improvements.

6.     The more common used and accepted term, Process Model, is a representation of an end-to-end process that is developed using a dynamic BPM tool. Process models allow analysts to manage large volumes of activities and run simulation events to identify areas in a process that can be changed and optimized.

7.     Process design is from process analytics to theoretic design; while process modeling is from theoretical design to implementation. Process design means identify existing processes and focus on the area like SLA, representation of the process flow, provide solution on bottlenecks during process flow etc., then based on these factors, design the process and prepare the process design document, so outcome is theoretical design. Process Modeling means representing a sequence of activities, events, decision gateways, links the sequence from end to end and taking the theoretical design to implementation using BPM tool. 

8.     Design is to create the idea of a wholly or partly new one (TO BE); a model will be its result. Thus, a complete design process should include modeling as a sub job. Modeling is a help to communicate about the design of a process with several stakeholders. Process Model means of graphically communicating how a process flows, could be 'as is' or 'to be' and there are different types of models and notations you can use, BPMN being one of them.  In context, Process Design is the blueprint for the selected implementation after you have modeled the process, evaluated and selected a design you are going with. Your intent with design is to go forward with the implementation. 

9.     Modeling can be seen as an evaluation activity (simulation and/or analytics review) prior, during or after the design phase. That said, modeling and design are not ONE shot activities. As soon as the design is implemented, the improvement team goes into a feedback loop to new evaluate models. Because you have to balance the art and science that goes back and forth between these two activities. For well understanding, a model is usually helpful for communication but not necessarily just for that. The use of a dynamic BPM tool can make process modeling easier, even more productive, but it is not an absolute necessity. Not all organizations have the depth of technical expertise, change appetite, or project budgets to extract the expected business benefit.

10.  Execution is final goal. So a model can have many stakeholders that want to know something about the process design. Business people, Improvers, system builders, audit people, etc. They can all be served by a model to let them know what they want to know about the process design. But in the end it is not about modeling or designing a process. It's about execution! Making your processes do what they promise.

11.  Moreover these activities are cyclic, you design the process, then model, execute, monitor, optimize then again back to design. It's continuous improvement cycle.

Process Analysis - Document how an existing process works / flows
Process Re-Engineering - Making improvements to an existing process
Process Design - Creating and / or documenting a new process

Read More

CIO as Chief Intelligence Officer: Dance with Big Data?

 It is putting the right person that knows how to lead (evangelize) the effort and bring the users to the information that will allow them to create the knowledge to change the way business is run. 

Information is life blood in modern businesses today; however, very few organizations reach such information maturity. What are the requirements to get the data dance? Are CIOs the best guys/gals to think, deploy and run Business Intelligence projects in their enterprises? Perhaps it's time for CIOs going back to their root, to master data and information, and fit in the original meaning of "I" in their title as Chief Information/Intelligence Officer.

CIOs can be the ideal people to deploy BI projects since CIOs are responsible for everything about IT. In addition, the role lends itself to having exposure to all aspects of the business and how all functional areas tie together. As such, the CIO has a perspective on the whole business, and its operations that few others in an organization can match.  

“Vision Implementation” is Team Work: While only the CIO can be expected to complete the technical implementation correctly, the entire management team must be involved in the "vision implementation" - making sure that the intention of the system is well-defined and met.  

Only if a CIO is an Information Evangelist - someone who can drive business thinking on what and how information can help compete better. CIO also needs to be an evangelist of performance, profitability and customer experience. There is a huge number of opportunities out there to effectively use information that already exists in organizations.  

CIOs can be a catalyst to a BI implementation, but a lot depends on the Business folks about how much they're able to see what the CIOs see... The reality in most organizations is that BI is conceptualized as a grand data warehouse that will take business places....and it often ends up being used to get reports that do not make any difference to a business. The key of  Business Intelligence is Information, not the technology. 

Putting the Right Person in Charge. Whether this is the CIO or a mid-level exec is not the issue. It is putting the right person that knows how to lead (evangelize) the effort and bring the users to the information that will allow them to create the knowledge to change the way business is run. 

The key to success is creating traction in a given BI project or (pick any word you like) is that the leader can sell it internally for the entire life cycle of the initiative. Many projects have failed or were severely underutilized due to unclear objectives, desire for the fancy IT solution, not realizing the importance of data management, and the inability to lead the troops in the new ways. There’s lack of the respect of understanding the business community and the limitations of the technology implemented.

Who would head up the BI initiative if not the CIO? The CIOs role is 80% business, 20% technology, as the CIO role continues to evolve to a more business focused executive with a core competency in IT, the CIO will have an intuitive understanding of the measures and dimensions required by functional areas to explore potential BI projects. He/she is the right person to bring the project to reality, but he'/she is not the only person who must decide what it must be when it gets there. It prompts the board of directors to take direct accountability for IT governance and to take responsibility for IT expenditure and projects. In other words, if the project impacts the well-being of the company, they all have to be involved.

Read More about magic "I" in CIOs:

CIO as Chief Inspiration Officer

CIO as Chief Improvement Officer

CIO as Chief Improvement Officer II

CIO as Chief Improvement Officer III

CIO as Chief Insight Officer

CIO as Chief Influence Officer

CIO as Chief Innovation Officer

CIO as Chief Intrapreneur Officer

CIO as Chief Integration Officer

CIO as Chief Intelligence Officer

CIO as Chief Information Officer

CIO as Chief Investigation Officer

CIO as Chief Investment Officer

CIO as Chief Interpretation Officer

CIO as Chief Inclusiveness Officer

CIO as Chief Imagination Officer

CIO as Change Agent

CIO as Governance Champion

Read More