Operational Excellence versus time-material

Gisterenavond heb ik een stuk gelezen in "het einde van management zoals wij het kennen" van Gary Hamel & Bill Breen [orignele titel : The Future of Management].
Het boek gaat over management vernieuwing a la Google en Whole Foods.

Vele ascpecten worden behandeld, maar een aantal onderwerpen kwamen samen uit drie bronnen, te weten de Computable, de Intermediair en het hierboven beschreven boek.
In het boek gesproken over Operational Excellence. Het toont meerdere keren aan dan het vooral de managemet style van een organisatie is die een organisatie voor lange tijd succesvol maakt.

Dit artikel beschijft mogelijkheden om een uren bedrijf om te vormen naar een producten bedrijf.

Quote uit het boek:"Dit getuigd van een van de belangrijkste axioma's van managementvernieuwing: voor concurrenten is het doorgaans moeilijker een onconventioneel managementmodel te imiteren dan een onconventioneel bedrijfjfsmodel te decoderen."
In de Intermediair staat een artikel over Jeff Jarvis (Dell schijnt zijn adviezen op te volgen om uit het slop te komen). In dat artikel zegt hij: "Doe wat Google doet".
In de Computable staat een volledig tegengesteld bericht over de Belastingdienst.
Men stapt af van de zelf sturende teams:"De fiscus werkte met zelfsturende teams en collegiaal management. Hierdoor waren de verantwoordelijkheden onduidelijk. Het wordt weer een klassieke hierchische organisatie."

Nu zoek ik (ons bedrijf) al langer een management model waarbij we ons bedrijf een concurrend voordeel kunnen geven. Maar niet alleen dat, we vinden dat we goed zijn in ons werk, maar ons huidige model hindert ons in onze ontplooiing. Dit resulteerd o.a. in klanten die minder tevreden zijn dan we (persoonlijk) zouden willen. Tevreden klanen zijn goed voor de omzet, maar ook goed voor onze gemoedsrust en ons persoonlijke succes.

Als bedrijf hebben we duidelijk concurrerende eigenschappen zoals innovatieve kracht, brede kennis internettoepassingen en een gestroomlijnd productie process. Echter, we zetten deze eigenschappen in op time-material projecten. Wie heeft er in zo'n geval baat bij operational excellence? In principe de klant, die heeft uiteindelijk minder kosten.
Maar, hoe is dit een concurerend voordeel t.o.v. van andere aanbieders?
Hoe kun je in onze markt de aanbieders met elkaar vergelijken?
Wat de klant van ons vraagt is in de regel een product dat nog niet eerder is gemaakt of een product dat gebruik maakt van innovaties. Dit houdt in de we geen commodities leveren, dat maakt een vergelijk met concurrenten dus lastig. Dan blijft over ons uur tarief. En dat is nu net niet waarop we willen concurreren.

Waarop willen we wel concurreren? Waarom vinden wij dat een klant bij ons moet komen shoppen? Op innovatie, kennis, inzet, betrokkenheid en vanwege ons software ontwikkel proces.
Dat zijn allemaal zachte eigenschappen die niet op de offerte staan. Hoe kunnen we deze wezenlijk goede eigenschappen ten gelde maken? Door ze in te zetten voor ons zelf.
Hoe kunnen we dat bereiken?
Door zelf producten te maken.
Dat kan een product zijn voor 1 klant (dit kun je ook een project noemen).
Het kan ook een product zijn voor meerdere klanten. Dat laatste vergt normaliter substantiele investerigen en een goed idee. Met een goed idee kunnen we die investeringen ook wel binnenhalen, maar zonder een goed iedee zullen we het moeten zoeken in het maken van specifieke producten op aanvraag (waarvan de klant eigenaar zal zijn).
Oke, we gaan zelf producten maken. Hoe zetten we het team van mensen hierop in?
De producten die we maken vragen om een variabele teamgrootte.
De teamsamenstelling is in het algemeen afhankelijk van de benodigde vaardigheden, de beschikbare informatie het beschikbare budget en de gewenste doorlooptijd.
Hierdoor is het team variabel, en werken de teamleden dus op verschillende projecten tegelijkertijd.

De samenstellig van het team is van groot belang. Hoe stel je deze samenstelling vast?
Dat kan van 'bovenaf' , maar analoog aan het model van Whole Foods zou een team ook zichzelf kunnen samenstellen. Ik stel met zo voor dat het bedrijf een lijst van projecten heeft.
Op die lijst kan men zich inschrijven. Zo zullen zich gelegenheidsteams vormen.
Het team wordt zo zelf verantwoordelijk voor het verkrijgen van de juiste vaardigheden (door het opnemen van de juiste teamleden). Gekoppeld hieraan wordt het team verantwoordelijk gemaakt voor zijn eigen succes. Het meten van dit succes is geen eenvoudige opgave. Denk aan budget v.s. kosten, doorlooptijd of klanttevredenheid. Publiceer deze gegevens van alle teams en er zal onderlinge concurrentie optreden. De teams zullen dus genegen zijn om de voor hun project/product beste beslissingen te nemen. Kleine teams zouden mensen kunnen 'inhuren'. Denk hierbij aan een GUI designer of een tester. Of een projectleider die voor hun de administratie doet.

What's in it for me? De onderlinge concurrentie is een motivator op zich.
Vooropgesteld dat het team tevreden is met het huidige salaris, zal het team in de nieuwe opzet dat ook zijn. Echter, men krijgt er wat bij en dat is zelfbestuur en ontwikkelingsmogelijkheden.
Als je 'atlijd' zelf mag kiezen wat je wilt doen en de teamleden elkaar uitzoeken zullen talenten zich makkelijker kunnen ontwikkelen. Als dit model het bedrijf succesvol maakt zullen de teamleden mee kunnen groeien. Het cooperatieve model zal eenieder de mogelijkheid geven om mee te kunnen groeien. Dit omdat eenieder in staat zal zijn om van de voor hem/haar belangrijke opportunities gebruik te maken.

Samengevat kan een bedrijf met specifieke concurrenende eigenschappen, dat nu projecten doet op basis van time-material gebruik maken van deze specifieke eigenschappen door:
- Producten te maken;
- De ontwikkeling van producten aanbieden aan teams;
- Ad-hoc teams zich laten inschrijven op de producten;
- De resultaten van de teams publiceren.

The Cloud

A webselfservice can easally be hosted in The Cloud.
The Cloud is like The Matrix. Is a worldwide network of computers, running virtual machines.
Everything in the cloud is virtual, but the servers living in The Cloud are not aware of this. So they run software like they were any physical server.

The good thing about The Amazon Cloud is that one can maintain their own servers like a virtual datacenter. Switching on a server is done with a click of a button.

Amazon has 2 datacenters in Europa, so they can guarantee that the data resides in Europa; which might be usefull in relation to legal issues.

Becaus the serves are completely virtual, and thus can run on any piece of hardware, the availability and scalability is high (or can be made high easally).
Up-scaling an existing server is easy and just takes a few hours.

Since the management of the servers is done by the customer, the customer can determine the level of support (and thus  save money).

SOA, webgateway and selfservice

Many companies are adapting SOA for various reasons.

If a company wants to create a public service, the SOA infrastructure could be a great platform for such a project.
In order to expose the existing SOA services to the internet, a couple of issues have to be addressed:
- Browser support
- Characteristics of on-line generated load
- Identity Management (authentication)
- Security (Authorisation)

These issues can be addressed by something I call a WebGateway.
Let me elaborate a bit on these issues.
The first and most import is support for browsers.
In order to reach a broad spectrum of users, all browsers should be able to use the exposed services. The 'old' way to do this is to expose the services using (D)HTML. A common way to do this is through a web application that generates HTML (like PHP, JSP, ASP, etc).
The downside of this is that the developer who creates the public service also determines the layout of this service (let's call this Web 1.0).

A new way to create public services is through REST style services, JSON or XML over HTTP.
This way, only the bare data is exposed, which enables frontend developers to use all their creativity to develop a slick and flashy website (let call this Web 2.0). Newly developed SOAP javascript libraries may give SOAP another chance on the internet.

The second issue is the load characteristics of on-line users in comparison to the way internal users are using the services.
The main difference is of course the number of users. For companies that offer public services (like telecom-, energy- and insurance companies) the on-line user base may be a 3-4th order bigger than the number of internal users (typical numbers for dutch companies are for B2B : 1000-10.000 and B2C : 10.000-2.000.000 users) .
In most cases where back-office system (mostly ERP or some kind of CRM/Customer Support system) are exposed by creating SOA services, the back-office systems are not designed for on-line use. Increasing the number of request by a factor 1000 or so may cripple the system and may render it unusable for the rest of the company (e.g. Customer Support).

This can be addressed by caching data in the WebGateway. The ways the cache can maintained will be discussed in a future blog.
The idea is that the WebGateway will try to serve as much data from its cache in order to decrease the load on the SOA services.

If customers are allowed to change their properties (like contracts, addresses and so on) authentication and authorisation is required. This is a specific attribute of the on-line channel.
The WebGateway can manage sessions with a on-line user and thus may provide services for authorisation and authentication. This can by combined with Identity management systems like Microsoft Active Directory, Crowd or LDAP.
More about this topic in future blogs.

Security is last on my list, but not on purpose. For IT departments and companies with a public exposure, this will always be a big issue.
I'll leave the firewall issues to the infrastructure experts, but the WebGateway may help by logging user activity or blocking users (for example by their ip-address).
The WebGateway may also use a technique called throttling to prevent misuse of Deniel of Service attacks.