Industriële standaardsoftware
Rechten en plichten

Hubert Lahaut, Control & Automation Magazine

version française

Reeds meerdere jaren worden zogenaamde standaard softwarepakketten voor diverse technische toepassingen aangeboden. Het voordeel dat van het gebruik van deze pakketten uitgaat is dat ontwikkeling in eigen regie, d.w.z. dat de inspanning voor het ontwerpen en programmeren van het informatiesysteem niet nodig, of in ieder geval beperkt kan blijven. Daar staat echter tegenover dat wel een diepgaande evaluatie van de op de markt verkrijgbare pakketten noodzakelijk is.

Echter, in veel gevallen kan men er niet zondermeer vanuit gaan dat een geschikt pakket gevonden zal worden, dat zowel aan alle functionele criteria voldoet alsook aan alle randvoorwaarden waarvan het kostenaspect veelal doorslaggevend is (eigen uren bij evaluatie, aanschaf van het pakket en eventuele hardware, gewenste wijzigingen, installatie, training gebruikers, e.d.). De problematiek van het evalueren van standaardpakketten ten behoeve van verschillende technische toepassingen is reeds geruime tijd onderwerp van studie geweest.

Doorgaans gaat men bij de evaluatie en selectie van standaardpakketten uit van de wensen ten aanzien van de gewenste functionaliteit en de budgettaire mogelijkheden die gelden op het moment waarop de eventuele aanschaf van een pakket actueel is. Echter, aangezien de inspanningen en kosten aanzienlijk kunnen zijn verwacht men over een langere periode nuttig van een pakket gebruik te kunnen maken. Het kan voorkomen dat de voorwaarden die bij aanschaf golden in de toekomst veranderen, wat mogelijk tot problemen bij zowel bestaande gebruikers alsook bij de softwareleverancier kan leiden.

Dynamiek
Het is een welbekend verschijnsel dat de samenleving niet stationair is, en dat geldt ook voor de industriële wereld. Gebruikers die eens tevreden waren met de geboden functionaliteit van een standaardpakket ontdekken later nieuwe mogelijkheden die men graag aan het gebruikte pakket wil toevoegen. Men kan verwachten dat in het bijzonder beginnende gebruikers nog niet aan het einde van hun ‘leercurve’ zijn aangekomen. Vaak zal er sprake zijn van een golfbeweging, waarin men geleidelijk nieuwe wensen opspaart en die vervolgens in één keer wil realiseren, zodra men voldoende argumenten heeft om een investering in dergelijke veranderingen kan rechtvaardigen. Vervolgens begint men weer met het opsparen van nieuwe wensen, enz. Het is echter ook denkbaar dat niet alleen vanuit een verbeterd inzicht in het beheersen van de eigen (productie)problematiek wensen tot verandering voortkomen, maar ook door de veranderingen in de werksituatie zelf een andere werkwijze in o.a. het productieproces noodzakelijk maakt. De kernvraag is dan in hoeverre een pakket veranderbaar is en welke consequenties hieraan verbonden zijn.

Een verstandshuwelijk
Vanaf het moment dat de gebruiker, als klant van de softwareleverancier, zijn handtekening zet onder het koopcontract begint het ‘verstandshuwelijk’ tussen gebruiker en leverancier. De gebruiker verkrijgt tegen betaling het gebruiksrecht van het softwarepakker, waarbij hij tegelijkertijd ook gebonden is aan een aantal (huwelijks)voorwaarden. De bedreigingen die bij een dergelijk huwelijk kunnen optreden komen voort uit tegenstrijdigheden in de belangen die beide partijen hebben. Enerzijds is de gebruiker er alleen in geïnteresseerd dat een pakket ten allen tijde voldoet aan zijn gewenste functionaliteit tegen acceptabele kosten, terwijl de softwareleverancier streeft naar maximalisatie van de winst. Dit laatste betekent dat het uiteindelijk de leverancier is die bepaalt welke wijzigingen structureel in zijn pakket zullen worden opgenomen, bijvoorbeeld in een nieuwe versie, dan wel welke wijzigingen hij klantspecifiek toelaat. Dit verschil in belangen kunnen we karakteriseren als ‘individualisme van de gebruiker’ en het ‘leveranciersdilemma’.

Het individualisme van de gebruiker
Na verloop van tijd kan zich de situatie voordoen dat de gebruiker nieuwe wensen in zijn pakket gerealiseerd wil zien. Doorgaans zal hij zijn wensen aan de leverancier voorleggen en om een offerte voor de uit te voeren wijzigingen vragen. Het spreekt voor zich dat klantenspecifieke wijzigingen door de leverancier of een derde uitvoerende partij volledig worden doorberekend, waarbij een leverancier ook gebruik kan maken van de afhankelijkheid die een klant nou eenmaal bij hem heeft. De contractvoorwaarden voor het gebruik van het softwarepakket leggen in veel gevallen beperkingen op aan de gebruiker ten aanzien van de aard van de wijzigingen die toegestaan zijn en wie geautoriseerd is om eventuele wijzigingen door te voeren. Het enige, meestal goedkopere, alternatief voor een gebruiker doet zich voor als de leverancier besluit om zijn wijzigingen tot een nieuwe ‘standaard’ werkwijze te verklaren die vervolgens in een nieuwe versie verwezenlijkt wordt. Mocht de leverancier met een dergelijk voorstel instemmen, dan betekent dit een mogelijke reductie in kosten van softwarewijzigingen voor die ene gebruiker, maar anderzijds kunnen de wijzigingen overbodig of zelfs nadelig zijn voor andere bestaande gebruikers. Een dergelijke wijze van aanpassen kan tot grote onvrede leiden als een leverancier enkele grote en vele kleine gebruikers heeft. Grote klanten kunnen uiteraard meer invloed uitoefenen en zullen dan ook een grotere kans maken dan ‘kleinere’ gebruikers om hun wensen als een nieuwe standaard door te zetten.
In het uiterste geval zou een individuele gebruiker kunnen beslissen om over te stappen naar een ander(e) pakket(leverancier) of over te gaan op softwareontwikkeling in eigen beheer. Echter, de kosten en risico’s bij dergelijke overstap kunnen groot zijn en uiteindelijk verandert er aan zijn afhankelijk zijn weinig. Deze wordt slechts verplaatst naar een andere partij.

Leveranciersdilemma
Aangezien de leveranciers uiteindelijk een winstoogmerk hebben, zullen zij er in principe naar streven om de inspanningen in software-ontwikkeling te minimaliseren en de opbrengsten uit verkoop van gebruiksrechten aan nieuwe gebruikers en betaalde aanpassingen te maximaliseren. Echter, beide opbrengstgerichte activiteiten houden een belangrijk dilemma voor de leverancier in, die een bedreiging kan vormen voor zijn continuïteit.
Men zou mogen verwachten dat door een groter aantal van een pakket te verkopen de ontwikkelkosten over meerdere gebruikers gespreid kunnen worden, terwijl er ook betere winstmarges voor de leverancier mogelijk worden. Het in grote getale verkopen van softwarepakketten aan nieuwe klanten zorgt op korte termijn inderdaad voor de verwachte inkomsten. Maar het aantal gebruikers en daarmee het potentieel aantal wensen tot veranderen/aanpassen zal ook toenemen. Het wordt daarmee voor leveranciers steeds moeilijker om aan alle wensen tegemoet te komen, zonder daarbij het principe van het standaardpakket te verlaten. Ook kan een grote gebruikersgroep remmend werken op de introductie van nieuwe versies, waarbij men recentere inzichten heeft verwerkt en verouderde inzichten heeft verwijderd.
De andere opbrengstgenererende activiteit, het aanpassen van het pakket naar de behoeften van individuele gebruikers kan voor een leverancier die veel ‘actieve’ gebruikers heeft, lucratief zijn, maar dwingt hem ook tot het bijhouden van een toenemend aantal configuraties van hetzelfde pakket. Zodoende wordt het steeds moeilijker om ook nieuwe versies, elegant passend en geen lapmiddel, te introduceren die rekening houden met alle bestaande configuraties. Het gevaar bestaat dat de kosten voor ontwikkeling van nieuwe versies zo hoog worden dat het niet meer concurrerend kan zijn en bestaande gebruikers gaan overstappen. Een leverancier van standaardsoftware zou zich natuurlijk kunnen opstellen zoals een leverancier van universele niet functiegebonden software, zoals tekstverwerkers en spreadsheets, en accepteren dat er nu eenmaal gebruikers vertrekken als er maar genoeg nieuwe bijkomen. Een dergelijke strategie gaat niet op in een industriële omgeving, aangezien gebruikers door de hoge kosten van overstappen gebaat zijn bij continuïteit tegen redelijke kosten.

Oplossingsrichtingen bij belangenconflicten
Het moge duidelijk zijn dat de ernst van bovenstaande belangenconflicten sterk afhangt van de werkelijke dynamiek in een gebruikersgroep en de vrijheid voor individuele aanpassingen die een leverancier toestaat c.q. in rekening brengt. Tevens kan er enige vertekening ontstaan door gebruikers die het evaluatie- en selectieproces niet voldoende zorgvuldig hebben doorlopen en eigenlijk een minder gelukkige keuze hebben gemaakt. Uiteraard kunnen zich situaties voordoen die gebruikers doen besluiten om de relatie met een leverancier te beëindigen.
Een tweetal bekende oplossingsrichtingen, te weten: gebruikersgroepen en modularisatie van softwarepakketten worden reeds toegepast maar bieden slechts in beperkte mate soelaas in de genoemde belangenconflicten. Nieuwe wegen kunnen gezocht worden door leverancier en gebruikers sterker aan elkaar te binden door een sterk gemeenschappelijk belang te ontwikkelen. Uiteindelijk is de menselijke vindingrijkheid de enige beperking in het vinden van nieuwe samenwerkingsvormen.

Gebruikersgroepen
Bij gebruikersgroepen kan men onderscheid maken in leveranciersafhankelijke- en onafhankelijke gebruikersgroepen. Groepsactiviteiten van leveranciersafhankelijke gebruikersgroepen worden in veel gevallen door de leverancier van een pakket gefinancierd en worden naast PR-doelen vooral gebruikt als medium voor productvoorlichting en om het animo voor geplande wijzigingen te polsen bij de bestaande gebruikers. Onafhankelijke gebruikersgroepen zijn in eerste instantie pressiegroepen t.o.v. hun leveranciers. Men hoopt meer druk op de leverancier uit te kunnen oefenen en daarmee zijn keuzes ten aanzien van pakketontwikkeling te kunnen beïnvloeden. In beide gevallen worden eventuele belangentegenstellingen niet verminderd maar mogelijk juist versterkt. Leveranciersafhankelijke gebruikers dienen voornamelijk het (korte termijn) commerciële belang van de leverancier en zijn erop gericht om de ‘band’ met de gebruikers te versterken. Onafhankelijke gebruikersgroepen kunnen vaak de individuele belangen (bvb. afwijkende behoeften in functionaliteit) binnen de groep niet overbruggen waardoor men genoodzaakt is zich te beperken tot secundaire aspecten, zoals een versoepeling van de contractvoorwaarden, verlaging van het ontwikkeluurtarief voor wijzigingen en dergelijke.

Modularisatie en partnership
Een mogelijkheid om met name verschillen in functionele behoeften van gebruikers te kunnen overbruggen is modularisatie van het standaardpakket door de leverancier. Hij kan door het aanbieden van verschillende modules de gebruiker in staat stellen naar eigen behoefte modules te selecteren en te combineren. De gebruiker heeft zodoende meer keus en de leverancier kan de ontwikkelingsinspanning concentreren op modules die meer aan verandering onderhevig zijn dan andere. Modularisatie is gericht op diversificatie van functionaliteit i.p.v. een standaard.
Een geheel andere benadering gaat uit van een partnershiprelatie tussen leverancier en gebruiker. Deze spreken met elkaar af onder welke voorwaarden nieuwe gebruikers worden ‘toegelaten’. Men kan er dus over waken dat bvb. een concurrent mee profiteert van de eigen gebruikersinbreng, dat alleen branchegenoten toegelaten worden, dat alleen gebruikers die dezelfde technische systemen gebruiken mee kunnen doen, enz. Bovendien bepalen de gebruikers gezamenlijk welke ontwikkelingen zij in het pakket wensen, zonder voorwaarden gesteld door de leverancier. Initieel kan een leverancier aan een groep gebruikers zijn pakket als geestelijk eigendom verkopen. Echter, de leverancier verliest hiermee in feite het autonome initiatief van klantenwerving en het uitbrengen van nieuwe versies. Om deze constructie ook voor de leverancier aanvaardbaar te maken zullen gebruikers een vooraf bepaalde financiële garantie aan de leverancier moeten kunnen geven, bijvoorbeeld in de vorm van een (toeslag op de) jaarlijkse huur voor het gebruiksrecht van de software. Een groot gedeelte van de belangentegenstellingen is hiermee weggenomen. De moeilijkheid bij dergelijke constructie is dat er een behoorlijke groep gebruikers moet zijn om de kosten voldoende laag te houden en toch de leverancier voldoende financiële compensatie te kunnen bieden. Voorts werkt deze ‘co-maker’ constructie alleen bij voldoende wederzijds vertrouwen.

Continuïteit
Bovenstaande rudimentaire benadering is niet uitgewerkt om als kant en klare oplossingen door te gaan. Bovendien zullen niet in alle gevallen de belangentegenstellingen zo groot zijn dat ingrijpende wijzigingen in leveranciersstrategie en in de relatie met de gebruikers direct noodzakelijk zijn. Belangrijk is wel dat de partijen zich realiseren dat het de gebruikers zijn die als probleemhebber het initiatief zullen moeten nemen inzake de richting waarin softwarepakketten (verder) ontwikkeld zullen moeten worden, waarbij de leverancier hen helpt dit streven te verwezenlijken. Men mag aannemen dat lang niet elke leverancier onverdeeld positief tegenover dergelijke voorstellen staat. Echter op termijn zal ook hij van een partnership­relatie de vruchten kunnen plukken doormiddel van het grotere vertrouwen en support van zijn gebruikersgemeenschap die hij nodig heeft voor de continuïteit van zijn activiteiten. <<

Logiciel industriel standard
Devoirs et obligations

Hubert Lahaut, Control & Automation Magazine

Des progiciels standard sont proposés depuis plusieurs années déjà pour diverses applications techniques. L’utilisation de ces progiciels a pour avantage de ne nécessiter aucun développement en interne – donc de n’exiger aucun effort d’utilisation et de programmation du système d’information – ou du moins, de le limiter. En revanche, il faut procéder à une évaluation rigoureuse des progiciels disponibles sur le marché.

De manière générale, il est faux de croire que l’on trouvera d’emblée un progiciel adéquat qui rencontre tous les critères fonctionnels ainsi que les conditions annexes, parmi lesquelles le coût constitue généralement le facteur décisif (les heures consacrées à l’évaluation, l’acquisition du progiciel et du matériel, les modifications souhaitées, l’installation et la formation des utilisateurs…). La problématique de l’évaluation des paquets standard pour diverses applications techniques fait depuis un certain temps l’objet d’études. Lors de l’évaluation et de la sélection des paquets standard, on s’appuie généralement sur les souhaits en termes de fonctionnalités et sur les possibilités budgétaires au moment de l’éventuelle acquisition. Cependant, comme les efforts et les coûts peuvent être conséquents, on escompte que le paquet pourra être exploité durant une période assez longue. Les conditions posées lors de l’acquisition sont susceptibles de changer au fil du temps, ce qui peut générer des problèmes tant chez les utilisateurs que chez les éditeurs de logiciels.

Dynamique
Il est bien connu que la communauté n’est pas stationnaire. Ce phénomène vaut également pour le monde industriel. Des utilisateurs qui se montraient au départ satisfaits des fonctionnalités proposées par un paquet standard, découvrent par la suite de nouveaux besoins qu’ils aimeraient pouvoir combler. On peut supposer que les utilisateurs débutants, en particulier, prennent plus de temps pour arriver à la fin de leur ‘courbe d’apprentissage’. On parle souvent d’un mouvement de vague durant lequel le client engrange progressivement de nouveaux souhaits qu’il veut ensuite réaliser d’un seul coup dès qu’il a suffisamment d’arguments pour justifier un investissement dans de telles modifications. Ensuite, il se remet à engranger de nouveaux souhaits… Il se peut aussi que les modifications souhaitées découlent non seulement d’une meilleure perception de sa propre problématique (de production) mais aussi de changements dans la situation de travail qui réclament une autre méthode de travail, notamment dans le processus de production. La question principale est de savoir dans quelle mesure un paquet peut être modifié et quelles conditions y sont liées.

Un mariage de raison
Le mariage de raison entre l’utilisateur et le fournisseur démarre dès l’instant où l’utilisateur, en tant que client de l’éditeur de logiciel, appose sa signature sous le contrat de vente. L’utilisateur obtient contre paiement le droit d’utilisation du progiciel mais il est simultanément lié à certaines conditions (de mariage). Les menaces d’un tel mariage découlent des conflits d’intérêts entre les deux parties. Pour l’utilisateur, le paquet doit à tout instant répondre aux fonctionnalités souhaitées et ce, à un prix acceptable, tandis que l’éditeur de logiciel vise à maximaliser son bénéfice. En d’autres termes, le fournisseur détermine en fin de compte lui-même les modifications qui seront reprises structurellement dans son progiciel, par exemple lors d’une nouvelle version, plutôt que d’implémenter toutes les modifications demandées par les clients. Cette divergence d’intérêts peut être définie comme .‘l’individualisme de l’utilisateur’ et le ‘dilemme du fournisseur’.

L’individualisme de l’utilisateur
Après quelque temps, l’utilisateur est susceptible de vouloir l’implémentation de nouveaux desiderata. Il soumettra généralement ses souhaits au fournisseur et lui demandera une offre pour ces modifications. Il va de soi que des modifications spécifiques au client seront entièrement facturées par le fournisseur ou par une tierce partie. Le fournisseur peut également profiter de la dépendance du client à son égard. Les conditions contractuelles relatives à l’utilisation du progiciel imposent souvent des restrictions à l’utilisateur quant à la nature des modifications autorisées et aux personnes autorisées à effectuer ces éventuelles modifications. La seule alternative, généralement moins coûteuse, dont dispose l’utilisateur, se présente lorsque le fournisseur décide d’implanter les modifications en question dans une nouvelle procédure de travail ‘standard’, qui sera ajoutée dans une nouvelle version. Si le fournisseur pouvait consentir à une telle proposition, cela pourrait signifier une éventuelle réduction des coûts liés aux modifications logicielles de cet utilisateur. Ces modifications pourraient cependant se révéler superflues ou néfastes pour d’autres. Une telle méthode d’adaptation peut générer un grand mécontentement si le fournisseur compte parmi ses clients quelques grands utilisateurs et de nombreux petits. Les gros clients peuvent en effet exercer une plus grande influence et auront dès lors plus de chances que les ‘petits’ utilisateurs à faire passer leurs souhaits sous la forme de nouveaux standards. Dans le cas extrême, un utilisateur individuel pourrait décider de migrer vers un autre paquet (fournisseur) ou développer sa solution en interne. Les coûts et risques d’une telle décision sont toutefois grands et, au bout du compte, son problème de dépendance sera simplement transféré vers une autre partie.

Le dilemme du fournisseur
Puisque les fournisseurs visent en fin de compte leur rentabilité, ils chercheront en principe à minimaliser leurs efforts en développement logiciel et à maximaliser les revenus provenant de la vente de droits d’utilisation à de nouveaux utilisateurs et d’applications rétribuées. Toutefois, ces deux activités génératrices de revenus confrontent le fournisseur à un important dilemme qui peut constituer une menace pour sa pérennité. On pourrait supposer qu’en vendant un plus grand nombre d’un même paquet, les frais de développement pourraient être répartis sur plus d’utilisateurs et permettre de meilleures marges bénéficiaires pour le fournisseur. La vente de progiciels en grandes quantités à de nouveaux clients assure en effet, à court terme, les revenus escomptés. Cependant, le nombre d’utilisateurs et la quantité potentielle de demandes de changements/adaptations augmenteront de pair. Les fournisseurs éprouveront donc toujours plus de difficultés à rencontrer tous les souhaits sans abandonner le principe du progiciel. Un grand groupe d’utilisateurs peut également freiner l’introduction de nouvelles versions dans lesquelles de nouvelles visions ont été intégrées et des concepts dépassés supprimés.
L’autre activité génératrice de revenus, l’adaptation du paquet aux besoins des utilisateurs individuels, peut être très lucrative pour un fournisseur qui compte de nombreux utilisateurs ‘actifs’. Cependant, cela l’oblige aussi à tenir à jour un nombre croissant de configurations d’un même paquet. De ce fait, il devient de plus en plus difficile d’introduire de nouvelles versions, versions élégantes et non palliatives, qui tiennent compte des configurations existantes. Les frais de développement de nouvelles versions peuvent devenir si conséquents que celles-ci ne sont plus concurrentielles et que les utilisateurs passent à autre chose. Un fournisseur de logiciels standard pourrait naturellement se positionner comme un fournisseur de logiciels universels, tels que les traitements de texte et les tableurs qui ne sont pas liés à une fonction, et accepter que certains utilisateurs partent pour autant qu’il décroche assez de nouveaux clients. Une telle stratégie est impensable dans l’environnement industriel puisque les utilisateurs ont tout intérêt, vu les frais élevés qu’entraîne une migration, à opter pour la continuité à des coûts raisonnables.

Lignes de conduite dans les conflits d’intérêts
Qu’il soit clair que la gravité des conflits d’intérêts décrits ci-dessus dépend fortement de la dynamique effective qui existe au sein d’un groupe d’utilisateurs et de la liberté d’adaptations individuelles qu’autorise ou facture le fournisseur. Il peut également y avoir de légères distorsions induites par des utilisateurs qui n’ont pas parcouru consciencieusement le processus d’évaluation et de sélection et qui ont en fait opéré un choix moins heureux. Certaines situations peuvent aussi inciter les utilisateurs à mettre un terme à la relation avec un fournisseur.
Il existe deux possibilités bien connues pour résoudre les problèmes, à savoir les groupes d’utilisateurs et la modularité des progiciels. Toutes deux sont déjà appliquées mais n’offrent qu’un faible répit dans les conflits d’intérêts cités. De nouvelles voies peuvent être trouvées en liant davantage le fournisseur et les utilisateurs par le développement d’un solide intérêt commun. En fin de compte, l’ingéniosité humaine est la seule restriction dans la recherche de nouvelles formes de collaboration.

Groupes d’utilisateurs
Dans les groupes d’utilisateurs, on distingue les groupes d’utilisateurs dépendant d’un fournisseur et les groupes d’utilisateurs indépendants. Les activités des groupes dépendant d’un fournisseur sont souvent financées par le fournisseur d’un progiciel et sont utilisées non seulement à des fins de fidélisation mais aussi comme moyen d’information sur le produit et dans le but de sonder l’enthousiasme des utilisateurs pour les modifications planifiées. Les groupes d’utilisateurs indépendants sont avant tout des groupes de pression par rapport aux fournisseurs. Ils espèrent pouvoir exercer une plus grande pression sur le fournisseur et influencer ainsi ses choix quant au développement du paquet. Dans les deux cas, les éventuels conflits d’intérêts ne sont pas aplanis mais renforcés. Les groupes dépendant d’un fournisseur servent principalement l’intérêt commercial (à court terme) du fournisseur et cherchent à consolider le lien avec les utilisateurs. Les groupes d’utilisateurs indépendants ne peuvent que rarement surmonter les intérêts individuels (des besoins différents en fonctionnalité par exemple) au sein du groupe. De ce fait, il faut se limiter à des aspects secondaires comme un assouplissement des conditions contractuelles, une réduction du tarif horaire de développement pour les modifications et autres…

Modularité et partenariat
La modularité du progiciel standard par le fournisseur est une possibilité permettant de surmonter notamment les différences de besoins fonctionnels des utilisateurs. En proposant divers modules, il peut permettre à l’utilisateur de sélectionner et combiner des modules selon ses besoins. L’utilisateur bénéficie dès lors d’un plus grand choix et le fournisseur peut concentrer l’effort de développement sur des modules qui sont plus sujets à des changements que d’autres. La modularité s’axe sur la diversification de fonctionnalité plutôt que sur un standard. La relation de partenariat entre le fournisseur et l’utilisateur part d’une toute autre approche. Ceux-ci conviennent ensemble sous quelles conditions de nouveaux utilisateurs sont ‘admis’. Les utilisateurs peuvent donc surveiller qu’un éventuel concurrent ne profite pas de leur apport, que seuls les collègues du même secteur soient admis, que seuls les utilisateurs utilisant les mêmes systèmes techniques puissent participer… En outre, les utilisateurs déterminent ensemble quels développements ils souhaitent dans le progiciel, sans conditions stipulées par le fournisseur. Le fournisseur peut au départ vendre son logiciel à un groupe d’utilisateurs sous la forme de propriété spirituelle. Dans ce cas, il perd toutefois l’autonomie d’acquisition de clients et la mise sur le marché de nouvelles versions. Afin de rendre ce montage également acceptable pour le fournisseur, les utilisateurs devront pouvoir donner au préalable une garantie déterminée au fournisseur, par exemple sous la forme d’un (supplément sur le) loyer annuel pour le droit d’utilisation du logiciel. Cela supprime une grande part des conflits d’intérêts. La difficulté d’un tel arrangement, c’est qu’il faut un groupe d’utilisateurs conséquent pour maintenir les coûts assez bas tout en offrant au fournisseur une compensation financière suffisante. Cette solution ‘co-maker’ fonctionne uniquement moyennant une bonne confiance mutuelle.

Continuité
L’approche rudimentaire citée ci-dessus n’a pas été élaborée pour être conçue comme une solution prête à l’emploi. En outre, les conflits d’intérêts ne nécessiteront pas toujours des modifications radicales dans la stratégie du fournisseur et dans la relation avec les utilisateurs. Il est toutefois important que les parties réalisent que ce sont les utilisateurs qui, confrontés à un problème, devront prendre l’initiative quant à l’orientation vers laquelle les progiciels devront être développés. Le fournisseur devra quant à lui, les aider à atteindre cet objectif. On peut comprendre que tous les fournisseurs ne soient pas unanimement positifs à l’égard de telles propositions. A terme, ils pourront toutefois bénéficier d’une relation de partenariat grâce à la confiance et au support accrus de la communauté d’utilisateurs dont ils ont besoin pour poursuivre leurs activités. <<