Archive for June, 2013

An interview with Antonio Valle Salas

June 27, 2013

This is the English translated version of Antonio Valle Salas interview. for the original in Spanish please go here.

IMG_20130626_155323-600853516

Antonio Valle Salas

1. Tell us about your experience with TFT13

Being part of TFT conferences is an incredible experience. When I participated at the first edition, in 2012, it was exciting because it was the first time something like that was organized. In this second edition everything was more mature and the competition to get selected among the 24 speakers was harder. It is not only about the conference’s media repercussion (it has generated more than 10 million social impact by twitter reach), also the organization, the sharing channels and the topics are profoundly innovative. Someone said TFT is the TED of ITSM and I think they are right.

2. This process mining stuff looks like a potent way for understanding Santard + Case patterns. But, when we still dont have records how can we prepare for latter process mining?

Ten or twelve years ago, that was the main problem faced by those starting with early process mining investigation. Nowadays, practically all information systems track process execution.

Anyway, the minimum attributes a log must contain in order to use it with process mining tools are:

    • Case ID
    • Activity
    • Timestamp
    • Operator

I believe there is no ITSM tool lacking this kind of information, since it is needed to ensure traceability for the executed actions.
The real problem comes when our process traverses multiple information systems hence log consolidation in one format must be achieved from different platforms with distinct formats must happen (the most popular case is trying to track a process “Order to cash”, where there may participate multiple information systems).

3. The CAPEX and OPEX dynamic duo. Is it always better to invest in processes allowing operational cost reduction?

🙂 I see you’ve searched well and have uncovered a document that has been written quite a long time ago! That paper has been written from a class I gave at university and my aim was to explain what today is known as a “technical doubt”.

The truth is the appropriate thing to do is to look for a balance between the different expenditure types, because one reflects a short-term thinking while the other (operational cost reduction) reflects a long term thinking.

Still, I think this topic has changed a bit as time goes by and now it is not so much about CAPEX versus OPEX, which is a relevant financial classification, more it has become “what is the money spent in IT for“, regardless of having or not cost recovery; for instance, all the new *aaS wave means that money is OPEX, even if in reality it is extending business.

4. Is Lean useful for Service Management? Is it not bet ter suites for industry?

This is another hot topic, even more when taking in account the value added by Rob England with his S+C approach.

Tradicionally, Lean was seen as a tool set meant mostly to cost reduction by standardizing and error elimination (waste). But this is a simplistic view of Lean.

Actually Lean is a management strategy that strives for maximising value delivered to the customer, and for that uses different paths. One path is cost reduction but problem identification, root cause search, introducing a continual improvement culture and putting in place best practices are some of many available tools.

This way, the relation between S+C and Lean is meaningful because within Lean we can find ideas, methods and tools that help us with the Standard part (where we can attack problems like standardization, variability reduction, flow leveraging and stock reduction) but also we can find great help for the Case part, where we have tools like Kaizen or the A3 thinking to apply the scientific method to case solving.

 It has been born within industry and can not be directly applied to service delivery practices, it has to be understood and adapted, but I firmly believe it is a good path to pursuit.

5. How do you see the future of ITIL® Training now with the Joint Venture?

Independently of the JV, I think ITIL® has right now it’s future somehow at stake. Slowly (at least in Spain), what before was a distinctive factor now has turned into an utility: using Nicholas Carr words, ITIL® does not matter, it is something everyone has…. if you dont have it, you loose reputation or contracts. but having it does not make you win more contracts.

So, I think JV has hard work ahead. On one hand it must incite the existing communities in ITIL market so they get back that feeling back from ITIL® V2, on the other hand it has to win back those communities and finally it has to come up with an innovative and attractive product (possibly combining the multiple reference frameworks it has, like ISACA has done with COBIT5).

And the training? If they keep dealing with it like a consumer market without ensuring certifications are credible, then ITIL® training is dead.

6. What new trends in Service Management are most promising for you?

Right now I think some trends are just being born and we will see they will become important in the next three to five years:

  • Process Mining
  • IT Governance and Corporate Governance of IT
  • Risk based Service Management
  • DevOps (but that wont be its name… it will be called Agile Service Management or something similar)

7. We finally realise ITSM is about people. So does regional culture affect the way we do ITSM? Eg is there Mediterranean ITSM? [a question from Rob England to Antonio]

Oh! Great question!

Yes, of course… there is a Mediterranean way of life, and living includes executing processes. During my professional life, that’s the most important problem I’ve found while helping companies to promote a service management initiative; every time I’m told that “we are not in Germany, we are not used to follow strict procedures”, and may be this is why it is so difficult to make the wheel move.

It’s fun that this question comes from Mr. Rob England. When I was reading Plus! Standard+Case, it surprised me that sometimes it proposes the idea that “we must accept that there exist another part of the reality that corresponds to the Case side of the coin”. In these Mediterranean countries, what we must accept is that there exists another part of the reality that corresponds to Standard (!). Moving this to the Cynefin framework, that locates us somewhere between Chaotic and Complex.

Una charla con Antonio Valle Salas

June 26, 2013

Aqui tienen muy interesante charla con Antonio Valle Salas. For English version please go here.

Antonio Valle Salas

Antonio Valle Salas

1. ¿Cómo fue tu experiencia en el TFT13?

Participar en las conferencias TFT es una experiencia increíble. Cuando participé en la primera edición, en 2012, fue emocionante porque era la primera vez que se organizaba algo así. En esta segunda edición todo ha sido más maduro y la competición por conseguir un puesto entre los 24 ponentes ha sido más difícil. No es sólo por la repercusión mediática del congreso (que ha generado más de 10 millones de impresiones en web) sino porque la organización, los canales de difusión y las temáticas son profundamente innovadoras. Hay quien ha comparado el TFT con el TED del ITSM, y creo que tiene razón.

2. Esto de la minería de procesos parece una herramienta poderosa para entender patrones Standard + Case. ¿Pero cuando todavía no hay registros con la información cómo puede uno preparar la prospección minera?

Hace diez o doce años, este era el problema principal con el que se encontraban aquellos que estaban comenzando con las primeras investigaciones en minería de procesos. Hoy en día prácticamente la totalidad de sistemas de información dejan rastro de la ejecución de los procesos.

En todo caso, los atributos mínimos que debe tener un log para poderlo incorporar en las herramientas de minería de procesos son:

  • ID de Caso
  • Actividad
  • Timestamp
  • Operador

En ITSM no creo que haya ninguna herramienta que no guarde este tipo de información, ya que es precisa para dar trazabilidad a las acciones realizadas. El problema serio viene cuando nuestro proceso atraviesa varios sistemas de información y entonces es necesario consolidar logs que vienen de diferentes plataformas con diferentes formatos en uno sólo (el caso más popular es intentar hacer la trazabilidad de un proceso tipo “Order to Cash”, donde pueden intervenir varios sistemas de información).

3. El dúo dinámico CAPEX y OPEX. ¿Es siempre mejor invertir en procesos que reducen los costes operacionales?

🙂 Veo que has buscado bien y rescatas un documento escrito hace mucho tiempo! Ese paper lo escribí a raíz de una clase que di en la universidad y estaba tratando de explicar lo que hoy se conoce con el nombre de “deuda técnica”.

En realidad lo adecuado es conseguir un balanceo adecuado entre los dos diferentes tipos de gasto, ya que uno refleja un pensamiento a corto plazo mientras que el otro (la reducción de costes operacionales) refleja pensamiento a largo plazo.

Aún así, creo que la temática ha ido variando un poco con el tiempo y ahora ya no es tanto CAPEX versus OPEX, que no deja de ser una clasificación financiera, sino se que ha convertido en “para qué sirve el dinero que gasto en TI”, independientemente de si hay amortización o no; por ejemplo, toda la nueva oleada de *aaS hace que el dinero sea OPEX, aunque en realidad esté ampliando las capacidades del negocio.

4. ¿Qué utilidad tiene Lean para Service Management? ¿No es mas bien aplicable para industria?

Este es otro de los temas candentes, más aún teniendo en cuenta la aportación de Rob England con su aproximación S+C. 

Tradicionalmente se ha visto a Lean como un conjunto de herramientas orientada especialmente a la reducción de costes por medio de la estandarización y eliminación de derroches (waste). Pero esa es la visión simplista de Lean.

En realidad Lean es una estrategia de gestión que busca maximizar el valor entregado al cliente, y para ello utiliza diferentes caminos. Uno es la reducción de costes, pero la identificación de problemas, la búsqueda de causa raíz, la introducción de una cultura de mejora continua y el despliegue de buenas prácticas son otras de las muchas herramientas de las que disponemos.

De esta manera, la relación entre S+C y Lean es importante debido a que en Lean podemos encontrar ideas, métodos y herramientas que nos ayudan en la parte Standard (donde podemos atacar  problemas como la estandarización, la reducción de la variabilidad, la homogeneización del flujo y la reducción de inventarios) pero también encontraremos grandes ayudas en la parte Case, donde tenemos herramientas como Kaizen o el pensamiento A3 para aplicar el método científico en la resolución de casos.

Es algo que ha nacido en la industria y que no se puede aplicar directamente sobre las prácticas de entrega de servicios, sino que se debe comprender y adaptar, pero creo firmemente que es un  buen camino a seguir.

5. ¿Como ves el futuro de la formación en ITIL® ahora con la Joint Venture?

Independientemente de la JV, creo que ITIL® tiene en estos momentos el futuro ligeramente comprometido. Lentamente ha ido ocurriendo (al menos en España) que lo que antes era un factor diferencial, ahora se ha convertido en una utility: parafraseando a Nicholas Carr, ITIL® does not matter, es algo que tienen todos… si no lo tienes, entonces te desprestigias o pierdes contratos, pero tenerlo no te hace ganar más contratos.

Así, creo que la JV tiene por delante un trabajo muy duro. Por una parte debe conseguir animar a las diferentes comunidades de su mercado para que vuelvan a sentir esa ilusión que se destilaba en los tiempos de ITIL® V2, por la otra tiene que volver a ganarse la simpatía de la comunidad y finalmente deberá utilizar las diferentes bazas que tiene para conseguir un producto innovador y atractivo (posiblemente combinando los diferentes marcos de referencia que tiene, de la misma manera que ISACA ha hecho con COBIT5)

¿…y la formación? Si la siguen tratando como un mercado de masas sin darle prestigio a las certificaciones, la formación en ITIL® está muerta.

6. ¿Qué nuevas tendencias en la gestión de los servicios te parecen prometedoras?

En estos momentos yo creo que hay algunas tendencias que están comenzando a nacer y que veremos que adquieren importancia en los próximos tres a cinco años:

  • Minería de Procesos
  • IT Governance y Corporate Governance of IT
  • Gestión de Servicios basada en Riesgos
  • DevOps (pero no se llamará así… se llamará Agile Service Management o algo parecido)

7. We finally realise ITSM is about people. So does regional culture affect the way we do ITSM? Eg is there Mediterranean ITSM? [a question from Rob England to Antonio]

Oh! Great question!

Yes, of course… there is a Mediterranean way of life, and living includes executing processes. During my professional life, that’s the most important problem I’ve found while helping companies to promote a service management initiative; every time I’m told that “we are not in Germany, we are not used to follow strict procedures”, and may be this is why it is so difficult to make the wheel move.

It’s fun that this question comes from Mr. Rob England. When I was reading Plus! Standard+Case, it surprised me that sometimes it proposes the idea that “we must accept that there exist another part of the reality that corresponds to the Case side of the coin”. In these Mediterranean countries, what we must accept is that there exists another part of the reality that corresponds to Standard (!). Moving this to the Cynefin framework, that locates us somewhere between Chaotic and Complex.

Service [Request?] Catalog

June 21, 2013

The main confusion I’ve seen lately among customers and colleagues is being able to distinguish between Service Catalog and Service Request Catalog.

Take it or leave it

Take it or leave it, from Flickr, by D Siegnowski, Some Rights Reserved

Keep this short (my aim is to make you access the resources at the end):

  • Service Request Catalog refers to what a user can ask for
  • Service Catalog is all an IT service provider offers to its customers

One can look at the Service Catalog in many ways. I find it useful to take the elephant in two portions, like this:

  • Internal supporting services; i.e those that support services delivered to customer
  • Business services; i.e all services the customer perceives

For the Business services I further detail in two:

    • Service Request Catalog; i.e services requested on demand by end users (some times only a selected few that have the authority/need to do so)
    • Continuous services; i.e services that IT delivers permanently (well, within service hours) like applications

Thus, activities around Business Relationship Management and Service Level Management capture customer representatives experience whereas Service Desk take care of end users experience.

You can watch good stuff on this by Ian Clayton here or read a post by Doug Mueller.

Wisdom is never on the menu, you have to own the restaurant – Carrie Latet

Agile Ops Manifesto – from Dave van Herpen [PT]

June 18, 2013

Thanks to Dave van Herpen for letting me translate this Agile Ops Manifesto! I recommend reading the whole post. Enjoy.

Alien Manifesto, Some Rights Reserved

Alien Manifesto 

Agile Ops Manifesto

De acordo com o Agile Manifesto, quatro princípios básicos podem ser identificados para Agile Ops. A mesma regra aplica-se aqui: do lado direito ainda é importante, mas do lado esquerdo é ainda mais importante. Por exemplo, conformidade com SLA é ainda importante, mas um cliente satisfeito é mais importante. Os princípios básicos são:

  • Satisfação do cliente      acima de    conformidade com SLA
  • Atitude e colaboração   acima de    certificação
  • Foco em resultados       acima de    foco em actividades
  • Adaptabilidade               acima de    procedimentos

6 factores de sucesso

1. Gestão de resultados

Se uma organização deseja tornar-se ágil na íntegra, acima de tudo implica uma mudança organizacional substancial. O estilo de gestão e a cultura deverão encorajar empreendorismo, independência (delegação) e responsabilidade operacional. SLAs consistem somente em KPIs que o negócio vê como úteis e serão usados como metas básicas ao longo de toda a cadeia de entrega. CABs são formados para permitir aceitação de alterações e releases frequentes, sem perda de tempo por parte das partes interessadas.

2. Colaboração na cadeia de operações e suporte

Hoje a cadeia de operações e suporte inclui vários fornecedores de IT internos e externo, que têm responsabilidade conjunta pela qualidade, operações, suporte e manutenção dos sistemas de informação. Num ambiente de operações ágil, colaboração proxíma entre todas as partes envolvidas é indispensável. Apontar o dedo ao outro (“não fomos nós, foste vós”) não é opção. Uma orquestração efectiva deverá facilitar esta forma de colaboração. Objetivos partilhados com espaço para comportamento proactivo são essenciais.

3. Adaptabilidade

Se por um lado a complexidade tem vindo a ser um desafio crescente para muitas organizações, a pressão para absorver alterações frequentes nunca foi tão forte. Quanto mais nos fiamos em estruturas, acordos e metodologias rígidas, menor será a capacidade da organização em combinar estas duas forças. Mapear e racionalizar o cenário aplicacional assegura recução da complexidade e facilita análise de impacto expedita e maior débito de alterações/releases.

4. Integração de operações e desenvolvimento

Ao encorajar colaboração entre desenvolvimento e operações e na entrega do valor esperado, vejo uma distinção cada vez menos nítida entre desenvolvimento e operações (DevOps). Cada vez mais, actividades de desenvolvimento, manutenção de releases, resolução incidents e tratamento de questões de utilizadores são endereçadas por uma única equipa. Negócio, projeto e operações juntam forças para atingir uma contribuição óptima a todo o ciclo de vida do IT.

5. Competências multidisciplinares

A produtividade de uma equipa integrada depende fortemente da competência individual dos seus membros. De modo a incrementar a produtividade da equipa, é crucial que os seus membros executem várias tarefas e se ajudem uns aos outros na criação de um fluxo óptimo para o trabalho em curso (WIP – Work In Progress). Isto inclui participação em actividades como análise, desenho, testes, implementação e suporte. A partilha de conhecimento entre perfis e competências é essencial aqui.

6. Ferramentas

O uso efectivo de ferramentas aumenta produtividade e promove a fiabilidade de processos e activtidades. Projectos e operações podem melhorar a sua colaboração, por exemplo partilha de informação sobre alterações e releases, situações de projecto, resultados de testes e retorno directo dos processos operacionais de volta para os programadores. Também automação de releases parece indispensável caso ocorram releases frequentes.

An interview with Rob England

June 11, 2013

This is a first and I loved it. Rob England, the IT Skeptic kindly answered my questions around his latest and truly remarkable Plus! Standard + Case book.

[This post did not quite see the light in a DevOps fashion… Now I know that WordPress app publishes posts on the fly. Tomorrow I’ll release the drawing too.]

Rob England, A.K.A. The IT Skeptic

Rob England, A.K.A. The IT Skeptic

1. Tell me how you ended up with that cover photo of your new book Plus! Standard + Case.

It’s in the Appendix: splitting a rock neatly into two halves

I would like to present a case for you: the spine has no title or author, how on Earth will I find your book in my bookshelf?

fair question.  Printing-on-demand offers less control over the print quality. In particular it’s hard to accurately position the spine, especially on such thin books.   I’ll try to get it on there.
Locating it is easy: (a) you’ll have it always lying around to refer to or (b) it’s the only one in your bookshelf with a pale blue spine with nothing on it 🙂

2. What is Standard + Case and why do we need this approach?

S+C sees the world of response (responding to anything from IT incidents to car accidents) as two parts: the standard stuff we can train people to do in a repeatable manner, and the uncontrolled part which we have to handle each time uniquely.  Lots of our ITSM thinking pretends that the whole world is or should be standardised.  Especially there is a school of thought that IT can be treated like a manufacturing factory, with CMM, SixSigma, Lean and DevOps leading such thinking. I think that is only half the story.

3. Can you tell me a bit more on how continual improvement works within C+S?

“C+S” or “S+C”? because C+S is a special case of S+C – see page 27.
CSI for the Standard part of our world is well discussed and documented.  Not so much for the Case part.
By formalising Case response, we now have policy, methods, and resources which can all be systematically improved.   And we have measurement mechanisms to drive and assess that improvement.
We review individual Cases to capture learnings.  We use those learnings to make improvements.  We also use statistics, but less so than in the Standard world, because they are less meaningful when each case is unique.

4. What kind of metrics are relevant when dealing with cases? How should service levels really be agreed?

the most meaningful metrics are external ones: the measurement of inputs and outcomes:

  • costs and resource usage
  • customer sat
  • successful resolutions

5. What about certifying Case workers and using gamification?

There are no(?) certifications applicable to IT right now. Internal accreditation of case workers is very important however; we shouldn’t hand the badge to just anyone.   So we must devise our own schemes to recognise who deserves it.   And we always should.  An external certification will always only be part of the picture.
Gamification seems a good fit to such accreditation.  As responders acquire skills, experience and certifications, they “level up” until the top level: case worker.

6. You’ve been defending the Slow IT way to deal with ever faster pace of business. Looks great but how do we actually put it in practice?

That’s my next book 🙂 

7. Now that the word is out, what developments do you foresee for Standard + Case?

I’m hoping S+C gets absorbed into the mainstream thinking.  e.g I’d like to see the thinking become part of “ITIL 4”, whenever that happens.
I’d like to see DevOps, Lean etc make more acknowledgement that much of the world can’t be standardised or automated.
I hope the Case Management movement grows, and brings us bodies of knowledge and certifications.

You can buy the book here: Plus! Standard + Case book