Sunday, June 30, 2013

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

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

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 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…

Saturday, June 29, 2013

A key foundation would be to approach the project from the perspective of being a business project, not an ITproject.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 ITproject.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:

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.

An Enterprise Architect may be skill in documenting what
others know but the EA must learn where the architecture can help improve
weaknesses and take advantage of organization 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.

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.

EA can become one of the communication
tools at senior leadership team, to keep every party at 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
process.

The Enterprise Architecture is used to
make strategic decisions to drive 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

This architectural description may
contain multiple views in order to convey the key concepts, and
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 an 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

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 ensuring that the EA program has clear goals, remains
focused, and is accepted throughout the enterprise. Communication MOST – EA practices require 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.

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 set apart the
relevant features and clarify the options at hand. Finally everyone
may agree or disagree. 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 agreement.

Respect is basis for any effective
two-way communication. Respect does not require an arbiter - it
requires a different mindset and a 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 a
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

Friday, June 28, 2013

The “I” in the CIO title is full of imagination; Chief Improvement Officer is a right fit for 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 business and co-develop strategy: He or she could be 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 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 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 hand off 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, 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 Insight Officer" is one of the most appropriate titles to be a digital IT leader.

Thursday, June 27, 2013

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

Wednesday, June 26, 2013

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 insidethe 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 changesThe 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

Tuesday, June 25, 2013

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

Information is life blood in modern businesses today; however, very few organizations reach such information maturity. Whatare 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.

6. 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.

7. 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.

Monday, June 24, 2013

One of the critical challenges of modern organization is the
need to respond in a high-velocity business environment -fast, dynamic,
highly-changing/fluctuating. In such cases, the process of traditional ways of
'Strategic Planning' itself is taking a hit. In such circumstance, how do you
see the role of Enterprise Architecture as a Strategic Planning Tool for the
company? How can EA help to discover business strategy? How should EA provide essential input to strategy, also capture outcome from it?

The capability of Enterprise Architecture practice is to
support the changing needs of the business, as we live in times where
the businesses are constantly under pressure to re-evaluate their strategy.
In traditional methods, strategy/planning & architecture decisions are
made "upfront" considering the number of uncertainties were
minimal or under control. However, this approach may not work
anymore. The EA practices should support the changing needs of the business.

In effect, EA becomes a key player in
an ongoing, dynamic 'strategic conversation' with and on behalf of
many others in the organization or overall enterprise. However, it is not
the only player in that 'conversation'; and to support the dynamic nature
of that conversation, the architecture needs to be much more versatile and
describe much more than a single static 'future state'.

Enterprise Architecture creates a platform that
enables strategic planning efficiently. The biggest value proposition
of EA is the integrated view of IT & business, further enabled by EA
repository tool; it brings slicing and dicing capability that can provide
tremendous inputs to IT Strategic Planning and can be leveraged further
for overall strategic planning of the organization.

EA is both an input to strategy
(business & IT) and an outcome from it. It's an outcome from
strategy because just about any strategic change will require some kind of
change of structure, policy or procedure - in other words, the 'content'
modeled within the architecture. It's an input because it describes the
structures and purpose of the enterprise, to guide strategic questions such
as:
- "Given this structure, what strategy can we support?"
- "If we change our strategy, what structures do we need to
change?"
- "What new options exist in structures that could support new
strategies?"
- "Does this strategy align with the enterprise purpose?"

Strategy and architecture are
fundamentally different, in fact are almost orthogonal: strategy
provides decisions, architecture primarily provides decision-support.
Often the boundaries between those two roles will blur, but we do need to
be aware that there’re good reasons as to why they should overlap.

Carefully differentiate between the
Architecture Practice and the Engineering Practice: the architecture
practice delivers meta-models. The engineering practice uses these
meta-models to build/change the real thing. Architecture is abstract,
meta-model driven, engineering is concrete model driven. Architecture
delivers the meta-model for Engineering. The EA Practice builds a
meta-model for enterprises. It is Enterprise Engineering that uses that
meta-model to model the actual Enterprise.
Part of the Enterprise Engineering goals is providing information for
strategic planning.

EA has the potential to provide direct
as well as indirect value to stakeholders. At the high-level, an
architect works primarily with patterns, but that isn't quite the same as
a meta-model. The term 'meta-model' has a very specific meaning, as
defining the formal structure for a model. The scenario is: In order for
architecture to become valuable, engineering has to follow, although EA
need not necessarily depend on enterprise engineering efforts. In deed, an effective Enterprise Architecture is a strategic planning tool in order to maximize the value being provided to business.