ERP-softwarereeks:ontwikkeling van gebruikersvereisten

Zodra een bedrijf de belangrijke waardeproposities heeft bepaald om verder te gaan met de selectie en implementatie van nieuwe of geüpgradede software, is het tijd om de gedetailleerde vereisten te formuleren die het nieuwe systeem moet ondersteunen. Deze vereisten zijn essentieel om de beste pasvorm en uiteindelijke waarde van de nieuwe oplossing te bepalen.

Twee categorieën vereisten

Vereisten moeten worden geclassificeerd als zowel "huidige toestand" als "toekomstige toestand". De huidige staatsvereisten worden gepresenteerd om potentiële leveranciers uit te leggen hoe het bedrijf vandaag de dag zaken doet. Het huidige bedrijfsproces wordt niet alleen beïnvloed door de huidige bedrijfsomstandigheden, maar ook door de beperkingen van de huidige software op de manier waarop transacties worden verwerkt en hoe uw bedrijf communiceert met zijn klanten en leveranciers.

Toekomstige staatsvereisten geven weer hoe het bedrijf van plan is in de toekomst te werken en software te gebruiken om het functioneren ervan te ondersteunen. De toekomst moet worden gedefinieerd in termen van 5 tot 7 jaar. Hoewel geen enkel bedrijf precies kan voorspellen hoe het over zeven jaar zal opereren, kan een bedrijf zich voorstellen hoe het van plan is zaken te doen en welke soorten software- en hardwaretechnologie het nodig heeft om zijn langetermijnstrategie te realiseren.

Bedrijfsproceskaarten

Bedrijven moeten ook nadenken over hoe ze informatie willen verzamelen over hun huidige en toekomstige activiteiten. Uiteraard is het verzamelen van informatie gebaseerd op de interactie tussen huidige gebruikers en degenen in de organisatie die verantwoordelijk zijn voor het presenteren van de verzamelde informatie aan leveranciers.

Sommige bedrijven zijn in staat om bedrijfsproceskaarten op te stellen die de volledige structuur van elk aspect van hun huidige staat en toekomstige staatsbedrijfsprocessen weergeven. Deze kaarten maken gebruik van input van degenen in het bedrijf die met transacties in een bepaalde bedrijfsactiviteit werken. Een lijst met mogelijke kaarten van zowel de huidige als toekomstige bedrijfsprocessen kan de volgende werkstromen bevatten:

• CRM
• Offerte en verkooporder invoeren
• Klantenservice
• Engineering – ter ondersteuning van offertes en ter ondersteuning van productie
• Toeleveringsketen/inkoop
• Magazijnbeheer/Voorraadbeheer/Ontvangen
• Plannen en plannen
• Werkorders en rapportage op de werkvloer
• Verzending
• Kwaliteit
• Boekhouding - Crediteuren en contante uitbetalingen
• Boekhouding – Facturering/debiteuren/contant geld
• Boekhouding – Grootboek

Bedrijfsproceskaarten moeten alle input en output bevatten met betrekking tot de huidige en toekomstige staatsbedrijfsprocessen. Deze activiteiten moeten worden "overlay" met indicatoren van welke software wordt gebruikt om de huidige actie te ondersteunen. Voorbeelden kunnen zijn activiteiten die gebruikmaken van het huidige ERP-systeem, activiteiten die gebruikmaken van MS Excel of Access Databases, of activiteiten die handmatig worden uitgevoerd.

Door de activiteit in kleur te coderen, kunnen lezers van de kaarten visualiseren hoeveel van elke technologie wordt gebruikt om de huidige en geplande bedrijfsprocessen te ondersteunen. Een van de zichtbare voordelen van de toekomstige staatskaart is de uniforme kleur van de nieuwe software die is gepland voor selectie en de eliminatie van andere kleuren, vooral die voor Excel-spreadsheets en Access-databases.

Checklists

Checklists worden al decennia lang gebruikt om software te selecteren. Checklists zijn meestal gebaseerd op de kennis van een derde partij die letterlijk honderden of duizenden functionele vereisten opsomt die vergelijkbaar zijn met de bovenstaande lijst. Veel van deze checklists zijn gekoppeld aan databases met ja/nee-mogelijkheden van een aantal softwareleveranciers. Door het invullen van de checklist beschikt de gebruiker over een lijst van ERP-leveranciers die het best in staat zijn om aan de behoeften van de gebruiker te voldoen.

De uitdaging van checklists is hoe de onderliggende database is ontwikkeld. Verkopers zijn niet altijd even duidelijk over de vraag of ze specifieke functionaliteit bieden, maar hoe de software de informatie daadwerkelijk levert.

Of de specifieke oplossing is voor een bedrijf met een omzet van $ 5 miljoen tot $ 25 miljoen of voor een bedrijf met een omzet van $ 250 miljoen tot $ 500 miljoen, moet worden verduidelijkt. Een extreem voorbeeld is dat SAP en Oracle functionaliteit bieden om de bovengenoemde bedrijfsprocessen te ondersteunen en dat geldt ook voor JobBOSS en E2 (populaire jobshop-oplossingen). Er moet een match zijn tussen de reikwijdte van de oplossing, de vereisten en het budget (waardevoorstel), evenals de industrie en de basisproductiestructuur tussen discrete productie en procesproductie.

Als een organisatie een checklist (service) gaat gebruiken, zorg er dan voor dat de checklist is ingevuld. Koop eerst het personeel dat verantwoordelijk is voor elk gebied en vervolgens beoordeeld door een bedrijfsbreed team dat individuele antwoorden kan relateren aan bedrijfsbrede operaties en behoeften.

Verhalen

De voorkeur van de auteur gaat uit naar een verhalend document dat de huidige staatsprocessen uitlegt en toekomstige staatsbehoeften bespreekt. Door de mensen in het bedrijfsproces te interviewen, kunnen verhalen worden gecreëerd die het verhaal vertellen van hoe het bedrijf vandaag loopt en hoe het in de toekomst wil opereren. Er kan een solide detailniveau worden gepresenteerd waarmee de verkoper het bedrijf volledig kan begrijpen. Narratieven kunnen ook worden aangevuld met wat het bedrijf doet, waarom het bedrijf op zoek is naar nieuwe software (de waardepropositie) en welke technologie er momenteel is.

Wat de verkoper wil beoordelen

Uit feedback die de auteur in het verleden heeft ontvangen, hebben de meeste leveranciers moeite om de bedrijfsproceskaarten volledig te volgen en zijn ze verveeld met checklists die 2000 functies lang zijn. Verhalen zijn gemakkelijker te beoordelen. Leveranciers besteden nog steeds veel tijd aan het stellen van vragen die al in alle drie de documenten zijn vermeld, dus bedrijven moeten voorbereid zijn om alle processen tot in detail te beoordelen, zelfs als er veel moeite wordt gedaan om de gebruikers- en softwarevereisten te ontwikkelen.

Aanzienlijke inspanning en zorg moeten worden gestoken in het ontwikkelen van gebruikersvereisten, aangezien wat is gedocumenteerd de basis vormt van hoe alternatieve softwareoplossingen zullen worden beoordeeld op geschiktheid, functie en waarde. Goed ontwikkelde gebruikersvereisten stellen een leverancier in staat om de meest complete presentatie te geven van hoe hun capaciteiten uw visie op toekomstig operationeel succes zullen ondersteunen.

Het is echt jouw schuld als de leverancier niet in de positie is om zijn capaciteiten zo goed mogelijk aan te tonen voor jouw bedrijf. Een oplossing van een leverancier die gemakkelijk waarneembaar is omdat hij niet aan uw basisbehoeften voldoet, mag nooit in uw vergaderruimte verschijnen voor een presentatie.

Harry Landsburg , DVIRC's Director of Business Process Technology Consulting, heeft met meer dan 300 bedrijven samengewerkt om te documenteren hoe hun bedrijfsprocessen het beste kunnen worden ondersteund door geüpgradede of nieuwe software. Zijn benadering van het relateren van de manier waarop zijn klanten werken aan de technologiemarkt resulteert in een betere selectie en implementatie. Voor meer informatie,  meer informatie  of  contact ons.