Der Beitrag The Future Role of IT erschien zuerst auf ACENT AG.

Der Beitrag Adaptive Governance erschien zuerst auf ACENT AG.

Der Beitrag Scaled Agility erschien zuerst auf ACENT AG.

The Wikipedia article on agile software development defines agile practices as follows:

“In software development, agile practices approach discovering requirements and developing solutions through the collaborative effort of self-organising and cross-functional teams and their customer(s)/end user(s). It advocates adaptive planning, evolutionary development, early delivery, and continual improvement, and it encourages flexible responses to change. It was popularised by the Manifesto for Agile Software Development. The values and principles espoused in this manifesto were derived from and underpin a broad range of software development frameworks, including Scrum and Kanban.”

The underlying principles of agile software development were already published in 2001 as part of the “Manifesto for Agile Software Development”.
It is an iterative approach to project management and software development that helps teams deliver value to their customers faster and with fewer headaches. Instead of betting everything on a “big bang” launch, an agile team delivers work in small, but consumable, increments. Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to changes quickly. Short iterative cycles (sprints) and reducing overhead and bureaucracy to a minimum and therefore delivering small parts of usable code with a true business value very quickly, is the essence of agile.

Speed is of the essence to be competitive in today’s business environment and that’s one of the main reasons why agile methods have become so popular. However, often agile is misunderstood by business managers and mostly seen purely as an “IT thing”. They often believe that with their IT teams adopting agile methods, projects are simply delivered faster and cheaper with the same scope. However, this is an illusion.

My personal experience going through an agile transformation as a CIO has taught me that to be able to reap the true benefits of agile methods, the whole company needs to become agile ‒ and this requires far more than just transforming IT. It is not enough to simply implement Scrum in IT, run a few projects the agile way, and believe that the company will then gain speed to market.
After we had used rapid prototyping methods for years and had co-located our IT teams with the business units, we started to introduce agile methods back in 2013. We experienced some benefits very quickly; by being able to deliver smaller chunks of ready-to-use software much faster than when employing the traditional waterfall methods. However, when trying to put the code into production, we got stuck with our own IT-internal ITIL-based processes. Our IT operations colleagues, who were rightfully charged to guard the “holy grail” of stable and secure operation, only allowed code to be promoted based on stringent processes and acceptance criteria at predefined points in time, e.g., when the monthly, or sometimes quarterly release cycles were due. We realised that we would only be able to overcome this bottleneck by including IT operations people in the agile teams (squads) and by making them and their processes part of the agile transformation. This was the advent of DevOps in the organisation.

While I see many companies stopping their agile transformation at this stage, as they consider agile to be an IT methodology, we wanted to take it further because we noticed that some other parts of the company were still slowing us down, inhibiting us from reaping the true benefits of agile methods.
Let me give a few examples of such “agile-inhibitors” in traditional, hierarchically organised companies. Any resemblance with actual people or organisation units of any company I worked for are purely coincidental:

• The marketing department refuses to get the new features of the mobile app put into production because a marketing campaign for promoting a set of new app features is only scheduled to take place in a few months.
• Finance refuses to release more funds because the budget for the year is already consumed and they insist that we put everything on hold until fresh funds would be approved as part of the regular yearly budgeting process.
• HR refuses to have the team recognised with an award for their excellent work and contribution after a key sprint because the regular yearly nomination process for the company’s “Chairman Award” just closed two months ago and the team should therefore be nominated for next year’s cycle.

I could probably go on with such examples of units and functions within the traditional hierarchical silos, but I guess you got the point by now: You cannot limit agile to IT if you want to benefit from the increased speed to market that agile ways of working offer. Instead, you need to drive the transformation all the way through the company.

Traditional planning and project management methodologies served us well in the past but are today as much of a legacy as the hierarchical structures that serve the bureaucratic processes and group functions of most enterprises. These hierarchical structures with their rigid planning and financial processes originating from the industrial age of the last century (Taylorism) are not suited for – nor are they compatible with – the new agile paradigm.

I observed that in traditionally run projects (waterfall method), teams spend a lot of time waiting for others to do something. In many project review meetings, when questioning why the project was behind schedule, one frequent explanation was “We are waiting for unit A to deliver X”. This can be bound to business units to sign off specifications or test cases, to run UATs, etc., or due to IT internal bureaucracy such as Enterprise Architecture to sign off the solution architecture, Cybersecurity to sign off the risks, IT operations to stage a server, etc., but also due to external factors, like a supplier of an outsourced component not delivering on time.
Why are we spending so much time waiting for others involved in the project?
Simply put, because of the clear task and role separation of the industrialisation approach, leading to multiple handovers and overhead.

A fellow CIO of a European bank and one of the strong promoters of agile ways of working told me a few years ago: “Agile is all about removing handovers. Handovers slow down processes and are the source of mistakes.”

In the novel “The Phoenix Project”, agile is accurately described as being about focussing on simplicity, the art of maximizing the amount of work not done. Similar to lean methods in manufacturing, it is about minimising “work in progress” and avoiding bottlenecks.

In his book “The Delicate Art of Bureaucracy”, Mark Schwartz describes how important it is to remove unnecessary bureaucracy to enhance agility.

In my view, agile is less about diligently following yet another methodology (Scrum, Kanban, SAFe, Holocracy, etc.) and again introducing bureaucracy as about a mindset, focussing on a few principles across the company and not only in IT:

• Reduce handovers, hierarchies and bureaucracy => focus on integrated and self-organising teams that can decide on their own with lean governance

• People positive attitude => trust people to get the job done, get out of the way, no micro-management or overengineered governance and processes
• Reduce the size of work packages and “work in progress” and therefore cycle times
• Constant on-going improvements vs. clearly defined projects and iterative adjustments vs. long drawn plans

As agile methods already have some tradition in IT, the CIO is well placed to drive the agile transformation across the company and to help the business colleagues become agile, by adopting these principles and by helping them to change the mindset within their organisations. This is an important part of the role of modern CIOs, who wants to add value to their companies and make a positive impact. Today’s CIOs are expected to get out of the back office, relinquish the traditional role of IT as a support unit and to move into the driver’s seat of the agile transformation across the business.

The eleventh part „Reversing the outsourcing madness => back-sourcing, or ‚How much IT to keep in-house?’”, will appear shortly. Questions, feedback and comments are highly appreciated: p.naef@acent.de

Resources:

• The (Delicate) Art of Bureaucracy: Digital Transformation With the Monkey, the Razor, and the Sumo Wrestler
  By Mark Schwartz, 2020
• The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win
  by Gene Kim and Kevin Behr, 2018
• Agile Manifesto: https://agilemanifesto.org/ , 2001

Der Beitrag The future role of the CIO erschien zuerst auf ACENT AG.

Der Beitrag Customer Usability: Herangehensweise ändern! erschien zuerst auf ACENT AG.

Der Beitrag Wie CIOs gerade jetzt ihren Einfluss deutlich steigern können erschien zuerst auf ACENT AG.

Gesamthaftes Benchmarking (IT Kosten in Prozent vom Umsatz) zeigt einem, wo man im Vergleich zu anderen Unternehmen der eigenen Branche liegt. Aber was sagt es aus? Ist ein niedriger Wert ein Zeichen für Effizienz oder eher eines für mangelnde Investitionen in die Digitalisierung? Amazon hatte sicherlich über viele Jahre relativ hohe IT Kosten in Relation zum Umsatz. Es war mit Sicherheit kein Fehler.

Differenziertes Benchmarking, z.B. Gesamtkosten pro Laptop, sind zwar aussagekräftiger, verursachen aber einen erheblichen Aufwand und es gibt immer die Frage nach der Vergleichbarkeit (sind z.B. die Netzwerkkosten mit enthalten) und Qualität der Vergleichsdaten.

IT Kostenoptimierung verlangt in jedem Fall ein wohlüberlegtes und zur aktuellen Ausgangslage passendes Vorgehen. Erfreulicherweise gibt es ein paar Hebel, die fast immer zielführend sind, insb. Standardisierung und Automatisierung der IT Leistungserbringung, Harmonisierung der (internationalen) IT Landschaft sowie Optimierung der Einkaufskonditionen. Aber diese müssen stets situativ passend angewendet werden.

Der Beitrag IT Kostenmanagement erschien zuerst auf ACENT AG.

Der Beitrag Schluss mit dem Innovationstheater! erschien zuerst auf ACENT AG.

At work, however, end users today expect the same simplicity and leading-edge technology that they are used to at home, and they are increasingly bringing their own technologies to the office. Restricting this and prescribing what technology, devices, tools, etc. may be used at work is becoming an ever more impossible task for CIOs. The younger generation want to use the technology and tools that help them to be efficient, and they do not care much about company standards and rules in this respect. They want to bring their own technology to work, connect their devices, access corporate systems and information as well as public internet at the same time with these devices and use the apps and software packages they are familiar with.

I remember having discussed the same topic back in 2014 with fellow CIOs, and at the time, the majority of them were convinced that their companies would never allow employees to connect personal devices to the corporate network. I wonder if this view has since changed, because back then I was already convinced that companies and in particular CIOs needed to rethink their policies if they wanted to be seen as a modern place to work and attract talent from the younger generation.

Companies will have to open their systems and networks to employees and allow them to connect their personal devices, tools and applications. The paradigm that companies provide their employees with all IT equipment needed for work is antiquated and no longer viable. The younger generation want to bring their own devices to work, such as smartphones, tablets, laptops, etc., and this trend will only increase. Whereas a few years ago, we were merely talking about “bring your own device” (BYOD), we are now confronted with “bring your own anything” (BYOx). With IoT spreading and all kinds of day-to-day objects becoming equipped with sensors and being connected, we will soon be seeing connected glasses, connected hearing aids, smart watches, connected shoes and clothing, etc. walk into our corporate offices. It is naive to think that CIOs will be able to stop these things from connecting to the corporate network. Moreover, as with the virtualisation of objects, more objects that we were using in physical form just a few years ago have been or will be dematerialised. They now “live” in the cloud and will need to be accessed together with corporate systems and apps that are also increasingly deployed to the cloud. Maybe corporate networks themselves will soon become obsolete or virtualised.

CIOs will have to accept that a significant part of the IT equipment and software will be procured by users and will no longer be manageable by a central IT organisation that is under the CIO’s control. On the other hand, CIOs will have to open up access to corporate IT resources, apps, systems, data etc. by user-controlled technology for collaboration purposes, while still ensuring the security of the corporate assets.

The next part will appear shortly. Questions, feedback and comments are highly appreciated: p.naef@acent.de

Der Beitrag The future role of the CIO erschien zuerst auf ACENT AG.

Der Beitrag Führung aus dem Homeoffice erschien zuerst auf ACENT AG.

Umstellungen des ERP Systems stellen ein komplexes Projekt mit erheblichen Kosten und personellen Aufwendungen für die Organisation dar. Dafür ist die Abwägung eines genauen Kosten-Nutzenverhältnisses unabdingbar.

Meine Erfahrungen als CIO, aber auch als Berater zeigen, dass die Voraussetzungen für ein Einführungsprojekt in den Konsequenzen oft nur unzureichend durchdacht werden. In welchen Bereichen ergibt sich der wesentliche Handlungsbedarf?

Geschäftsmodell, Organisation

Unterstützt das bestehende Geschäfts- und Organisationsmodell den angestrebten Nutzen einer ERP Umstellung? Die Erfahrung zeigt, dass standardisierte Abläufe keine Unschärfen in den Verantwortlichkeiten tolerieren. Hieraus ergibt sich typischerweise eine Diskussion über regionale versus Produkt-Verantwortlichkeiten.

Standardisierte Geschäftsprozesse

Geschäftsprozesse sind in der Regel in den Unternehmen nicht standardisiert. Selbst wenn die in den ERP Systemen hinterlegten Abläufe vereinheitlicht sind, ist die Handhabung doch unterschiedlich.

Stammdaten

Standardisierte Geschäftsprozesse setzen standardisierte Stammdaten voraus, d.h. single point of truth für Artikel, Dienstleistungen, Debitoren, Kreditoren, Kontenrahmen, Bewertungen etc.

Die Bearbeitung aller oben aufgeführten Punkte stiftet ihren Nutzen unabhängig von einer ERP Einführung. Sie ist aber auch Voraussetzung für eine Einführung, die den maximalen Nutzen aus den Standards und den state of the art Geschäftsprozessen ziehen will.

In der Praxis werden diese Themen zwar gesehen, aber in Anbetracht des Zeit- und Kostendrucks sowie organisatorischer Widerstände nicht konsequent umgesetzt. Das Ergebnis dieser Projekte ist zwar eine Umstellung des ERP Systems, aber das mögliche Nutzen-Potential wird nur bedingt erreicht.

Meine Empfehlungen:

1. Schaffen Sie klare Verantwortlichkeiten für Geschäftsfelder (Produkte, Dienstleistungen, regional, zentral, etc.).
2. Schaffen Sie klare Verantwortlichkeiten für das Stammdatenmanagement.
3. Benennen Sie Geschäftsprozess-Owner mit Kompetenz.
4. Gliedern Sie Ihr Projekt in zwei Teile:
   • einen businessgetriebenen Teil, der die o.g. Themen incl. des notwendigen Changemanagements umsetzt und in
   • einen IT getriebenen Teil, der sich um die technische Umsetzung kümmert wie Architektur, Cloud, technische Implementierung, etc.

Der Koordination dieser beiden Projektäste sollte durch eine Gesamtprojektleitung sichergestellt werden.

Das oben genannte Vorgehen hat sich in verschiedenen Projekten bewährt. Es setzt aber die Bereitschaft des Managements zu grundlegenden Veränderungen voraus.

Der Beitrag S/4HANA? Dann aber richtig … erschien zuerst auf ACENT AG.