http://www.kotterinternational.com/the-8-step-process-for-leading-change/
martes, 28 de octubre de 2014
lunes, 27 de octubre de 2014
jueves, 23 de octubre de 2014
What’s a Business Architecture?
What’s a Business Architecture?
http://www.ronross.info/blog/2014/10/07/what%E2%80%99s-a-business-architecture/
miércoles, 22 de octubre de 2014
Enterprise Architecture – Zachman vs TOGAF
None of the methodologies and features of EA are suitable for all the enterprises all the time. EA is continuously evolving and rapidly so in the past few years. The benefits of implementing EA are
- Improvements in business processes.
- Improvements in IT infrastructure
- Improvements in business and IT relationship
- Improvements in the achievement of business objectives and goals.
Governance Videos
Planificación y organización en Cobit. GOBIERNO DE TI
https://www.youtube.com/watch?v=yQ0IPa79bHo
Cómo determinar la capacidad de los procesos en COBIT 5
https://www.youtube.com/watch?v=fskJELjF3Z4&feature=youtu.be
martes, 21 de octubre de 2014
lunes, 20 de octubre de 2014
The Seven Rs of Knowledge Management
http://gestionconocimientoti.blogspot.com.es/2013/12/the-seven-rs-of-knowledge-management.html
Who raised the change?
What is the reason for the change?
What is the return required from the change?
What are the risks involved in the chance?
What resources are required to deliver the change?
Who is responsable for the build, test and implementation of the change?
What is the relationship between this change and other changes
domingo, 19 de octubre de 2014
miércoles, 15 de octubre de 2014
martes, 14 de octubre de 2014
What’s a Business Architecture?
http://www.ronross.info/blog/2014/10/07/what%E2%80%99s-a-business-architecture/
What’s your definition of business architecture? Here’s ours:
a structural representation of a business solution as it relates to creating business value and achieving business goals
Like most practitioners we mean a blueprint.
Actually, blueprint doesn’t completely align with the dictionary definitions of architecture.[1] You can take your pick from the following alternatives, but not one of them refers to a representation of what is being built.
1. Art and Science: the art or practice of designing and building structures … in accordance with principles determined by aesthetic and practical or material considerations
2. Structure: formation or construction whether the result of conscious act or of growth or of random disposition of the parts … e.g., architecture and function of the cerebral cortex
3. Specific Result: instance of the exercise of the art or science of architecture … architectural product: architectural work … e.g., the mansions which comprise the entire architecture of the Square
4. Method of Style: a method or style of building characterized by certain peculiarities of structure …
The first definition above refers to architecture as an art and science. That’s what architecture students go to universities to learn, and what professional architects practice daily. Who today really thinks of business architecture as an art and science? It should be – and it probably will be eventually – but it’s not yet.
The first definition also highlights principles. Any viable approach to business architecture must enumerate its principles and adhere to them closely. That’s not just so much talk. The approach must provide proper thinking tools so that you can consistently act in accordance with the principles.
Do most current approaches to business architecture provide such thinking tools? I think not. If they did, they would feature:[2]
- Business policies (in the context of business strategy), business rules, and decision engineering. Those things represent the intellect of the organization and the fundamental answer for question why.
- A carefully factored approach whose component models cover each of the facets needed to communicate effectively with all the different audiences engaged with, or affected by, a business solution.
Let’s face it. Many techniques currently offered for ‘business architecture’ frankly aren’t even really about the business. They’re about – what else – IT’s view of the business.
Some related points:
1. We think that business architecture always involves some amount (often pervasive) of organizational transformation, which can be taken to include building a new business solution completely from scratch. Organizational transformation is inevitable, so other than buzzword appeal, there’s really no need to mention it in the definition of business architecture.
2. Architect can be used as a verb (to plan and contrive as an architect). Too bad “architecting” doesn’t roll off the tongue as easily as “designing” or “modeling”. After all, architecting business solutions is exactly what business architects should be doing daily.
lunes, 13 de octubre de 2014
5 Key Components of a Successful Enterprise Architecture Function
http://blogs.salesforce.com/company/2014/08/enterprise-architecture-function.html
Creating and managing a successful enterprise architecture function requires a variety of different hard and soft skills. In addition, each company is different, and the enterprise architecture function needs to calibrate and align itself to the specific company.
With this in mind, there are five common features of a successful enterprise architecture function that apply to all companies:
1. Governance
Enterprise architecture (EA) requires governance, however not in the form of complex documents, forms or processes. The best governance starts with a simple, recurring dialogue across multiple functions facilitated by EA. I am always amazed at how valuable it is just to get cross-functional teams to talk.
Pick a specific topic, typically a critical pain point, which might be some business capability, and create a dialogue about how it works today. Each function will be able to share their perspective of how it “works,” and usually it’s educational for everyone in terms of learning how other groups are impacted. An enterprise effort can exist only when a cross-functional group of business functions prioritize that effort.
2. Talent
In my opinion, the best enterprise architects (EA) must have two critical qualities, pragmatism and business acumen, in addition to deep technical skills. Yes, it is important that they have good communication skills, good influencing skills, and are good at simplifying complex topics. But pragmatism and business acumen are critical as an Enterprise Architect.
A pragmatic EA is able to articulate current state, propose a future state and then pragmatically articulate a reasonable way to head towards that future state. Probably the hardest job of the EA is to find a path forward that is realistic given the current state architecture and the myriad of other constraints related to budget, resources and time. Perfection is the death sentence of enterprise architecture because it will lead to paralysis. Doing nothing means that systems will continue to atrophy. EA must find a way to move forward leveraging a pragmatic approach.
3. Executive Sponsors
For enterprise architecture to get real traction, you need the most senior level executive sponsors. The optimal situation is to get sales and customer service executives because revenue and customer are usually the highest priority in most companies. Regardless, get executive sponsors who have a strong, respected voice in your company. You don’t need every executive as a sponsor but you do need a critical mass. The reason for executive sponsors is that some of the tough decisions need to be driven top-down—only so much can be lead through grassroots activities. Common enterprise standards, policies, and governance require executive sponsorship.
4. Scope
Be careful not to over-scope EA. Pick a few key enterprise-level business pain points and start with those. Most EA teams have limited resources and budget (like all of IT) so pick your priorities wisely. Do a few things really well and avoid the trap of trying to kick off too many initiatives and spread your EA team too thin. It is sometimes difficult to reduce your scope when there are many challenges to choose from, but partner with your business partners to determine one or two key focus areas.
5. Business Value
EA must demonstrate business value. This means that the business functions must feel and articulate that EA is a value-add. The best way to accomplish this is to focus on improving business capabilities so that the business teams really feel the positive impact of EA. For example, if entitlement or your sales compensation process are broken and the business sees those are critical capabilities, focus on those.
Be wary of just doing “systems consolidation” projects or “technical upgrade” projects. Yes these are necessary but may not provide tangible business value. Always include some “wow” projects such as mobile apps or collaboration solutions. Find visible and exciting projects that motivate your EA team and add business value.
Visit salesforce.com for more on how our products support the enterprise archtecture role and download the free guide to building enterprise mobile experiences, 10 Essential Elements of Great Enterprise Mobile Apps.
Enterprise Architecture 101 for CEOs
This brief article intends to throw some light into a highly misunderstood discipline that CEO's could otherwise use to their advantage. The discipline goes by Enterprise Architecture Management (EAM), or simply Enterprise Architecture (EA). Too many people, including some enterprise architects, regard EA as an IT concern. That is backward thinking! As its name implies, Enterprise Architecture is anenterprise concern.
A Definition of Enterprise Architecture
Enterprise Architecture is a management and governance discipline that translates business strategy into effective enterprise change by designing the required business capabilities, and planning and guiding the implementation of the changes to those capabilities using a holistic approach.
Why You Need an Enterprise Architecture Function
As a CEO you own a strategy to take your organization to the next level of success. But all too often you have been disappointed by the inadequate execution of your strategy. There is a good reason for that: you have entrusted the execution of your strategy to the wrong parties. Forgive my bluntness, but you are among the many CEOs who have not heard about or quite grasped the concept (and value) of Enterprise Architecture.
EA will take your strategy, analyze your existing business capabilities against it, and identify what changes are needed in order to match your business capabilities to your strategy. Then, it will go on to plan the implementation of those changes. While designing and planning, it will juggle several factors: your organization’s values, stakeholders’ concerns, drivers, constraints, and risks. Next, it will ensure that the parties in charge of implementing the changes are compliant with the design. Finally, it will continually ensure that the deployed capabilities do indeed deliver the expected business value.
Note that I have not used, nor do I need to, Information Technology (IT) in my above discussion. This is because EA is a holistic discipline; it designs, plans, and governs considering all verticals across the organization and all domains from strategy to operations. No-one else in your organization has this vantage point – neither Strategic Planning, nor Governance, nor Project Portfolio Management, nor any other function. That’s why you need EA.
Conclusion
I have succinctly described what EA is, how it operates, and what their purpose is. I have also made a distinction between Enterprise Architecture and IT architecture. Finally, if you really want your EA function to succeed, you need to be bold enough to take it under your wing. Don’t put it under any other CxO, they will not know what to do with it.
martes, 7 de octubre de 2014
Matriz RACI–ITIL
http://es.it-processmaps.com/productos/itil-raci-matriz.html
RASCI – una ampliación del modelo RACI
El Mapa de Procesos ITIL utiliza una matriz RASCI para visualizar las responsabilidades de los roles ITIL en los procesos ITIL.
En RASCI, una ampliación del modelo RACI, se encuentran las siguientes responsabilidades:
- R - Responsible (responsable de la ejecución)
Alguien que desempeña una tarea determinada. Para cada tarea en un proceso ITIL existe normalmente un rol ITIL responsable de su ejecución. - A - Accountable (responsable del proceso en conjunto)
Alguien que asume la responsabilidad conjunta final por la correcta y completa ejecución de un proceso y que recibe las informaciones de los responsables de la ejecución del proceso. Normalmente, el Responsable de Proceso asume la responsabilidad conjunta de un proceso y para cada proceso existe un Responsable de Proceso. - S - Support (apoyo)
Alguien que apoya un rol ejecutivo en un proceso, contribuyendo a la implementación de una tarea en un proceso. - C - Consulted (consultado)
Alguien que no está implicado directamente en la ejecución de un proceso pero que da algún tipo de input para el proceso y/o al cual se pide su consejo y opinión. - I - Informed (a informar)
Alguien que recibe las salidas (outputs) de un proceso o a quien se informa de los avances del proceso.
Las matrices RACI tienen sobre todo sentido si múltiples roles asumen diferentes niveles de responsabilidad en varios procesos:
Ayudan como simple instrumento a comunicar responsabilidades de forma inteligible y contribuyen a evitar conflictos de competencias.
lunes, 6 de octubre de 2014
domingo, 5 de octubre de 2014
COBIT 5 Syllabus
http://vinsys.in/training-courses/cobit5-foundation-training/#tab-id-6
Module 1. Overview of COBIT®5 Workshop
Workshop Overview
Module 2. Principle 1: Meeting Stakeholder Needs
a) COBIT®5 5 Goals Cascade
- Step 1. Stakeholder Drivers Influence Stakeholder Needs
- Step 2. Stakeholder Needs Cascade to Enterprise Goals
- Step 3. Enterprise Goals Cascade to IT-related Goals
- Step 4. IT-related Goals Cascade to Enabler Goals
b) Using the COBIT®5 5 Goals Cascade
c) Benefits of the COBIT®5 5 Goals Cascade
d) Using the COBIT®5 5 Goals Cascade Carefully
e) Using the COBIT®5 5 Goals Cascade in Practice
f) Governance and Management Questions on IT
g) How to Find an Answer to These Questions
Module 3. Principle 2: Covering the Enterprise End-to-end
a) Governance Approach
b) Governance Enablers
c) Governance Scope
d) Roles, Activities and Relationships
Module 4. Principle 3: Applying a Single Integrated Framework
COBIT®5 Framework Integrator
Module 5. Principle 4: Enabling a Holistic Approach
a) COBIT®5 Enablers
b) Systemic Governance and Management Through Interconnected Enablers
c) COBIT®5 Enabler Dimensions
d) Enabler Dimensions
e) Enabler Performance Management
f) Example of Enablers in Practice
Module 6. Principle 5: Separating Governance From Management
a) Governance and Management
b) Interactions Between Governance and Management
c) COBIT®5 Process Reference Model
Module 7. Implementation Guidance
a) Introduction
b) Considering the Enterprise Context
c) Creating the Appropriate Environment
d) Recognizing Pain Points and Trigger Events
e) Enabling Change
f) A Life Cycle Approach
Getting Started: Making the Business Case
sábado, 4 de octubre de 2014
miércoles, 1 de octubre de 2014
Suscribirse a:
Entradas (Atom)