CPM-softwareselectie - De drie fouten die u moet vermijden

Een geschikte CPM-oplossing vinden is geen raketwetenschap

Er staat veel op het spel bij het zoeken naar de juiste CPM-oplossing; verkeerde beslissingen kunnen vaak ernstige gevolgen hebben. BARC-analist Dr. Christian Fuchs beschrijft de drie meest voorkomende fouten en legt uit hoe ze kunnen worden vermeden.

Veel bedrijven gebruiken Excel als de standaardoptie voor het weergeven van rapportage- en planningsprocessen - meestal voor het gemak ("we hebben het al en het kost niets"). Maar uiteindelijk komen de meeste mensen op een punt waar de Excel "pijn" te veel wordt en ze een gespecialiseerde CPM oplossing nodig hebben. Maar de juiste kiezen is makkelijker gezegd dan gedaan.

In mijn rol als analist bij BARC heb ik de afgelopen zeven jaar bedrijven geholpen bij het selecteren van Business Intelligence (BI) en CPM-oplossingen. In die tijd heb ik opvallend vaak dezelfde fouten zien optreden in softwareselectieprocessen. Dit zijn geen kleinigheden, maar ernstige fouten die het succes van een project enorm in gevaar kunnen brengen.

Om je te helpen deze gevaren in je project te beheersen, heb ik de drie meest voorkomende fouten samengevat met een aantal handige tips om ze te vermijden.

Fout #1: Rommelige requirements analyse

De basis van elk softwareselectieproces is een solide requirements analyse. Verbazingwekkend veel bedrijven falen echter bij deze eerste stap. Terugkerende klassieke fouten zijn onder andere:

• IT zoekt naar een 'geschikte' tool voor bedrijfsafdelingen zonder hen te betrekken bij de eigenlijke requirements-analyse.
• Requirements worden alleen verzameld in beperkte gebieden van het bedrijf, zonder alle relevante afdelingen te raadplegen.
• Te kortetermijndenken: Een tool wordt simpelweg gekozen omdat het de grootste pijnpunten aanpakt zonder rekening te houden met waarschijnlijke toekomstige vereisten.

Als u zich in een of meer van deze situaties bevindt, zouden de alarmbellen moeten gaan rinkelen! Je loopt het risico dat je een beperkte eisenanalyse uitvoert.

Mijn tip: maak een grondige functionele, technische en organisatorische requirements analyse in alle business units die naar verwachting met de software gaan werken. Dit moet zowel bedrijfsafdelingen als IT omvatten om acceptatieproblemen te voorkomen wanneer de tool in gebruik wordt genomen.

• Absoluut noodzakelijke en gewenste functies, evenals de gebruikerskring van de software, moeten worden geïdentificeerd binnen de functionele behoeftenanalyse.
• De analyse van de technische vereisten houdt zich bezig met gegevensbeveiliging, vereiste en haalbare prestaties, platforms en besturingssystemen en databasetechnologie.
• Het aantal gebruikers en de ondersteuning van verschillende soorten gebruikers (power user, ad hoc gebruiker, eindgebruiker) door middel van de functionaliteit van de tool is gebaseerd op de organisatorische selectiecriteria.

Als resultaat van de analyse van de vereisten wordt een volledige catalogus met criteria opgesteld, waarmee de softwareoplossingen die worden overwogen, kunnen worden geëvalueerd en gekwalificeerd. Omdat niet alle criteria even belangrijk zijn, moet elke eis worden gewogen. Alleen belangrijke criteria moeten worden toegepast voor de voorselectie ('short list') om de markt efficiënt te beperken op basis van een kleine selectie van relevante beoordelingspunten. Andere, minder belangrijke criteria moeten later worden overwogen bij de gedetailleerde evaluatie van de shortlist van producten.

Het volgen van deze richtlijnen zal helpen om een solide basis te leggen waarop later in het project een geschikte CPM-oplossing kan worden gekozen.

Fout #2: De leverancier kiezen, niet de oplossing

Vanaf het begin alleen focussen op "grote" en bekende softwareleveranciers is een fout die veel bedrijven maken, vooral in kleine en middelgrote bedrijven. "Kleinere" en gespecialiseerde softwareleveranciers hebben vaak zeer goede oplossingen en een grondiger begrip van de vereisten op basis van factoren zoals geografische locatie, industriesector en bedrijfsgrootte.

Het is begrijpelijk dat bedrijven zich zorgen maken over de keuze voor een "kleinere" leverancier. Bij het afwegen van de veiligheid van hun investering kunnen besluitvormers bijvoorbeeld denken dat het waarschijnlijker is dat een kleinere leverancier wordt overgenomen of failliet gaat. De grootte en het profiel van een leverancier mogen echter geen KO-criterium zijn in het selectieproces. Bedenk dat de continuïteit van een product niet noodzakelijk gegarandeerd kan worden alleen omdat het geleverd wordt door een "grote" leverancier. Ook zijn de grootte van een leverancier en de kwaliteit van zijn product niet altijd met elkaar gecorreleerd.

Bij je keuze moet je vooral rekening houden met het volgende:

Groter is niet noodzakelijk beter - zogenaamd "grote" leveranciers zijn niet noodzakelijk superieur in alle opzichten in vergelijking met hun "kleinere" rivalen. De pure grootte of bekendheid van een leverancier is geen geldig beslissingscriterium.

Draagt het totale pakket van technische en functionele ondersteuning op basis van de eisen van uw organisatie bij aan een redelijke prijs-prestatieverhouding? Factoren zoals ondersteuningsservices op locatie, hoe de leverancier zijn klanten behandelt, ondersteuning in lokale talen en regionale/industriespecifieke kennis zijn slechts enkele van de overwegingen die u niet mag onderschatten bij het selecteren van software. Onze ervaring en onderzoek toont consequent aan dat "kleinere" leveranciers meestal beter presteren dan de "grote" wereldwijde leveranciers op deze punten.

Fout #3: Geen proof of concept

Het kan riskant zijn om een gedetailleerde evaluatie van de oplossingen op uw shortlist over te slaan vanwege tijdgebrek of financiële redenen. Oplossingen moeten worden onderzocht met betrekking tot alle relevante vereisten (en kosten) en op de proef worden gesteld als onderdeel van een gedetailleerde evaluatie. Dit helpt bij het creëren van investeringszekerheid en minimaliseert het risico op het nemen van de verkeerde beslissing.

Het doel van een gedetailleerde evaluatie is om een accuraat beeld te krijgen van de mogelijkheden die de software te bieden heeft. Testinstallaties, gestructureerde softwarepresentaties en prototypecreaties ("proof of concept") zijn hier op hun plaats, idealiter gebaseerd op prestatie-eisen en gegevens die zo realistisch mogelijk zijn in termen van hoe de organisatie de software uiteindelijk wil gaan gebruiken.

Het is ook raadzaam om externe adviseurs en referentiegesprekken met klanten te raadplegen om feedback te verzamelen over leveranciers en producten van andere projecten en bedrijven. Met name de feedback van andere gebruikers die dagelijks met de oplossing werken, kan buitengewoon waardevol zijn om licht te werpen op mogelijke problemen en uitdagingen die zich kunnen voordoen als de oplossing eenmaal in gebruik wordt genomen.

Conclusie

Het vinden van een geschikte CPM-oplossing is geen raketwetenschap. Neem deze tips ter harte en je vergroot je kansen op een nauwkeurig en succesvol selectieproces.

Belangrijk: Vermijd de fouten die ik hierboven heb geschetst en let op de waarschuwingssignalen. Stuur het project actief weer op de rails als je merkt dat er iets fout gaat. Kennis van de best practice-aanpak voor softwareselectie en de veelvoorkomende valkuilen zal de kans op een slechte beslissing of het mislukken van het project aanzienlijk verkleinen.

Gewapend met deze tips staat niets een succesvol CPM softwareselectieproject in de weg. Ik wens u veel succes met uw eigen vlekkeloze selectieproces!