lunes, 30 de diciembre de 2013
sábado, 28 de diciembre de 2013
viernes, 27 de diciembre de 2013
miércoles, 25 de diciembre de 2013
martes, 24 de diciembre de 2013
domingo, 22 de diciembre de 2013
viernes, 20 de diciembre de 2013
BonitaSoft Ejemplo en Tiempo Real 35min (debéis registraros en el portal)
8 simple rules for achieving 'Lean IT'
What is the difference between Six Sigma, Lean, and PMP?
Lean Leadership Training
SCRUM vs. Kanban
is Kanban agile?
Kanban and Agile
What is Kanban? Kanban Software Tools
Where are Your Business Rules … In a Big-P Process Dead Zone?
jueves, 19 de diciembre de 2013
What you need to do to innovate
martes, 17 de diciembre de 2013
Webinar: Implementing BIAN Service Domains using the IFX Business Message Specification
lunes, 16 de diciembre de 2013
viernes, 13 de diciembre de 2013
What is Business Transformation?
Business transformation is a fundamental change in the way a business operates. Every company needs to continuously transform itself to stay ahead of the game, and to avoid slowly diminishing amongst the changing world around them.
Every consulting firm involved in business transformation will have its own variation of a definition, but the Business Transformation Academy provides us with the following:
“Business transformation is defined as a complex organizational change process affecting the entire value chain that has the potential to radically alter the company’s relationship with the wider economic and societal environment.”
Consult Llewellyn adopts the Business Transformation Academy’s BTM² framework which is made up of the following management 8 management disciplines:
- Strategy Management
- Value Management
- Risk Management
- Business Process Management
- Transformational IT Management
- Programme and Project Management
- Organisational Change Management
- Competence & Training Management
70% of transformations fail. Most due to insufficient attention to non-technical challenges such as value management, programme management and change management, and the mis-alignment of all management disciplines that span the transformation. Managers in transformation contexts often know what to do, and yet they fail to execute.
Engage external expertise to ensure your initiatives are managed as holistic business transformation programmes, encompassing the 8 management disciplines shown above. Don’t be another organisation that is sold a collection of IT projects which will be led by people who know IT transformational management well; but very little about the other 7 management disciplines of business transformation.
CONTACT CONSULT LLEWELLYN
Find contact details on our contact page here.
- See more at: http://www.consult-llewellyn.com/what-is-business-transformation/#sthash.H4oecsar.dpuf
jueves, 12 de diciembre de 2013
miércoles, 11 de diciembre de 2013
The Transformative Power of Enterprise Architecture - See more at: http://www.ecommercetimes.com/rsstory/74508.html#sthash.WrsOvLOO.dpuf
miércoles, 4 de diciembre de 2013
Capabilities are in fact the building blocks of business. A business capability typically defines what a business unit‘s purpose is (goals and objectives), its core competencies, and is therefore directly bound to business objectives and strategy. Capabilities provide a black-box view of those things the business can do, i.e. working on business artifacts (e.g. Business Processes, Catalogs). -
martes, 3 de diciembre de 2013
lunes, 2 de diciembre de 2013
domingo, 1 de diciembre de 2013
One of the most common mistakes that people make about Enterprise Architects is the notion that we are problem solvers. Yes, EA solves problems, but to frame EA in those terms is like saying that an ER Doctor is a bandage changer.
To help clarify the distinction between a “problem solver” and an Enterprise Architect, I will illustrate the logical argument for both, and show their differences.
Task: understand the problems and solve them
Task: understand the opportunities for the enterprise to be better aligned to its vision and focus attention on them.
- Find people who know what the problems are, and ask them.
- Look for root causes to those specific problems, narrowing focus to the ones that contribute to a desirable outcome.
- Describe solutions to those problems
- Collect and analyze information to understand the organization.
- Design the organization to meet the desired level and type of value delivery.
- Design ways to change the organization and ask why they didn’t already change on their own.
- Look for root causes and underlying challenges.
- Focus attention on the obstacles that prevent normal mechanisms from addressing the problem.
Results: well understood problems that are commonly ignored get solved (without addressing “why they were ignored”).
Results: opportunities that no one wants to see or problems that people are afraid to solve are discussed and addressed.
The left column is what business analysis is for. It is what solution architecture is for. It is NOT what Enterprise Architecture is for. I don’t care how good you are at doing the stuff on the left. I don’t care how well it has worked for you in the past while working as an EA. The “raison d'être” of EA is not to solve well-understood problems. It exists to find out why the organization hasn’t seen the obstacles that actually prevent success, hasn’t removed them, and hasn’t figured out how to cope with them.
Five blind men describe an elephant, each in different ways. The EA is the sixth blind man. He listens to the other five and says “the problem is not that an elephant is like a fan or a rope or a wall… the problem is that it is standing in the living room, and dropping large amounts of waste on the floor. Problem solvers try to find a better way to feed the elephant and remove it’s waste. Enterprise Architects asks why everyone is standing in the same room as an elephant.