Projectmanagement

Jira weet precies wat er met een issue is gebeurd. Iedereen buiten Jira hoort het later, of nooit

Een bug wordt opgelost en het issue doorloopt zijn workflow naar "Done". De klant die hem meldde hoort niets, want het enige dat is gebeurd is een transitie binnen Jira, en niemand heeft een stap gebouwd die het doorgeeft. Een projectmanager wil het aantal openstaande issues op een klantdashboard, en krijgt dat door een developer te vragen te kijken en in Slack te antwoorden.

Jira is precies over wat er met een issue is gebeurd en wanneer precies. Die precisie reist nergens vanzelf naartoe — een transitie, een custom field of een comment blijft binnen Jira totdat iets gebouwd is om het naar buiten te dragen.

  • Cloud en Data Center vragen een andere route
  • Custom field-ID's één keer gemapt, overal gebruikt
  • Vanaf € 1.700 plus servicekosten
De tool

Wat Jira is, en waarom Cloud en Data Center twee verschillende koppelingen zijn

Jira is een issuetracker rond projecten, issuetypes (bug, taak, story, epic), workflows en transities tussen statussen. Custom fields zijn hoe een team iets toevoegt dat het standaard issuescherm mist — een klantkenmerk, een ernstniveau, een specifieke vervaldatum — en elk daarvan krijgt een interne ID zoals customfield_10047 zonder relatie met het zichtbare label, vaak verschillend tussen projecten binnen dezelfde omgeving.

Jira Cloud wordt door Atlassian gehost, bereikbaar over internet met een gedocumenteerde REST API en OAuth. Jira Data Center draait op je eigen servers of die van een hostingpartner, meestal achter een firewall, met een eigen REST API die overlapt met die van Cloud maar er niet identiek aan is. Welke van de twee je draait bepaalt de koppelroute voordat iets anders dat doet — een connector gebouwd voor Cloud wijst niet zomaar naar een Data Center-URL en werkt dan.

Wat er misgaat

Drie dingen die misgaan rond een Jira-omgeving

De eigen gebruikers van Jira voelen dit zelden — de workflow binnen Jira klopt meestal wel. Het is iedereen die er net buiten staat die voor het gat betaalt.

Een klantopmerking landt in Jira, en de klant ziet het antwoord nooit

Support loopt via een portaal of formulier dat een Jira-issue aanmaakt, een developer antwoordt door op het issue te reageren, en de reactie blijft binnen Jira omdat niets hem naar buiten draagt. De klant ververst een pagina die nooit bijwerkt, en mailt vervolgens of iemand ernaar kijkt — terwijl iemand er al sinds dinsdag naar kijkt.

Wat je in plaats daarvan ziet

Een reactie op een gekoppeld issue wordt teruggezet in het portaal van de klant of rechtstreeks naar hem gemaild, met alleen-intern bedoelde reacties eruit gefilterd zodat niets dat voor het team bedoeld is naar buiten lekt.

Het dashboard dat iedereen wil is een persoon, die ververst

Een klant of manager wil open issues, resterende story points of de sprint burndown zien zonder in Jira in te loggen. In de praktijk wordt dat een wekelijkse screenshot, of iemand die getallen in een spreadsheet overzet, wat verouderd is voordat het verstuurd wordt en fout zodra een status een uur later verandert.

Wat je in plaats daarvan ziet

De getallen worden live uit Jira gelezen via de API naar een dashboard of portaalpagina, zodat wat een klant ziet is wat Jira op dat moment echt zegt, niet wat het vorige week dinsdag zei.

Een veld-ID dat in het ene project iets betekende, betekent iets anders in een ander

customfield_10047 is in het ene project "Klantkenmerk" en in een ander "Ernst", want velden worden per project aangemaakt en Jira hergebruikt ID's op een manier die niet duidelijk is uit het label. Een koppeling die op basis van de velden van één project is gebouwd en aanneemt dat de rest overeenkomt, leest of schrijft het verkeerde zodra er een tweede project bijkomt.

Wat je in plaats daarvan ziet

Wij mappen veld-ID's expliciet per project en controleren de mapping voordat de koppeling live gaat op een nieuw project, in plaats van aan te nemen dat hij overloopt.

De rekening van het handwerk

Wat handmatig rapporteren en doorgeven rond Jira kost

Het duidelijkste getal is de statusupdate. Besteedt een projectleider vijftien minuten per dag aan het verzamelen van issue-aantallen en sprintstatus voor een klant of manager, dan is dat ruim vijf uur per maand aan het terugvertalen van Jira's eigen gegevens naar een zin die Jira zelf had kunnen zeggen.

Het gat in supportreacties is lastiger te vatten maar kost vaak meer: een klant die moet mailen om te vragen of iemand zijn ticket heeft gelezen heeft besloten dat het supportkanaal niet werkt, en die beslissing duikt nergens als kostenpost op — hij duikt de volgende keer op als telefoontje in plaats van ticket.

Wat we bouwen

Wij bouwen ook het ding aan de andere kant

Bij Jira zit de koppeling bijna altijd in iets groters — een klantportaal, een supportformulier op de website, een dashboard — want ruwe Jira-issues zijn niet iets wat je een klant rechtstreeks zou tonen.

Een koppeling heeft twee kanten. Er zijn genoeg bureaus die de API-call voor je bouwen en je een JSON-payload overhandigen; dat is de makkelijke helft. De moeilijke helft is waar die data in landt — een website, een webshop, een portaal waar je klanten op inloggen, een intern hulpmiddel dat een spreadsheet vervangt. JKC bouwt beide kanten, en daarom blijven de koppelingen die wij bouwen meestal werken: aan de ontvangende kant is voor ons niets een zwarte doos.

API-koppelingen

De koppeling zelf: authenticatie, veldmapping, rate limits, retries en een wachtrij die overleeft dat het andere systeem een uur uit de lucht is. Gebouwd op de gedocumenteerde API als die er is, en op wat de leverancier werkelijk aanbiedt als die er niet is.

Websites

WordPress-sites die uit je systemen lezen in plaats van ze met de hand na te typen: een vacaturepagina die uit je HR-systeem komt, een teampagina die je salarisadministratie volgt, prijzen en beschikbaarheid die de echte zijn.

Webshops

WooCommerce-shops waarin de order de laatste keer is dat iemand hem intypt: hij wordt een factuur in je boekhoudpakket, een label bij je vervoerder, een voorraadmutatie in je warehouse en een regel in je CRM, uit zichzelf.

Webapplicaties

Als het proces in geen enkel standaardproduct past: een klantportaal, een offertetool, een planbord, een dashboard dat drie systemen tegelijk uitleest. Gebouwd op jouw data, met jouw systemen als bron in plaats van een kopie ervan.

Wat er gekoppeld kan worden

Wat er tussen Jira en de rest van je stack gekoppeld kan worden

Alles hieronder werkt zowel op Cloud als Data Center, maar niet via dezelfde route — we checken welke editie je draait voordat we iets afbakenen.

  • Website- of portaalformulieren als nieuwe issues (in de tool)

    Een supportformulier of bugmelding op de website maakt een issue aan in het juiste project met issuetype, prioriteit en custom fields al ingesteld, in plaats van een mail die iemand met de hand tot ticket moet maken.

  • Transities en reacties naar de melder (uit het gereedschap)

    Een issue dat naar een gekozen status gaat, of een openbare reactie die wordt toegevoegd, bereikt de melder per mail of in een portaal — met alleen-interne reacties eruit gefilterd.

  • Issue-aantallen en sprintstatus naar een dashboard (uit het gereedschap)

    Open issues, resterende story points of een sprint burndown, live uit de API gelezen en getoond op een klant- of interne dashboard, in plaats van een wekelijkse screenshot.

  • Issues gelijk gehouden met een CRM of een projecttool (beide kanten)

    Een issue gespiegeld als taak in HubSpot, Productive of een andere projecttool, gematcht op de issue-sleutel, voor teams die aan de developmentkant de workflow van Jira nodig hebben en voor de rest iets eenvoudigers.

  • Op een issue geboekte tijd naar facturatie (in de tool)

    Worklogs op een issue opgeteld per klant of per epic en doorgegeven aan een boekhoudpakket als factureerbare uren, zodat een factuur weerspiegelt wat Jira echt heeft geregistreerd in plaats van een aparte urenstaat.

Een eerste Jira-project is meestal het paar formulier-in en status-uit; de CRM-spiegeling en de facturatieregel volgen meestal zodra die twee zich hebben bewezen.

Hoe het werkt

Hoe een koppeling bij JKC gebouwd wordt

Elke keer dezelfde vier stappen, om welke tool het ook gaat. Niets hiervan is een workshop waar je voor betaalt: stap één bestaat omdat een koppeling verkeerd afbakenen het duurste is wat er met zo'n koppeling kan gebeuren.

  1. 1. We kijken wat er nu écht wordt overgetypt

    Niet "welke velden bestaan er" maar "welke velden verplaatst iemand nu met de hand, hoe vaak, en wat gaat er stuk als het misgaat". De meeste projecten blijken twee of drie stromen nodig te hebben, geen volledige tweerichtingssync van alles. Dat gesprek is wat de offerte laag houdt.

  2. 2. We kiezen de route, en zeggen waarom

    Een onderhouden connector van de leverancier, een platform als Make of Zapier, of een maatwerkkoppeling op de API. Goedkoopste eerst, niet maatwerk eerst: als een ondersteunde plugin precies doet wat je nodig hebt, dan is dat het antwoord en zeggen we dat ook. Maatwerk is voor de gevallen waarin de kant-en-klare optie zoveel configuratie vraagt dat hij juist het fragiele onderdeel wordt.

  3. 3. We bouwen hem zo dat hij het andere systeem overleeft

    Elke koppeling krijgt retries, een wachtrij en een idempotency-sleutel mee, zodat een order die binnenkomt terwijl de andere kant eruit ligt later wordt afgeleverd in plaats van verdwijnt, en een retry geen tweede factuur aanmaakt. Eerst op een testomgeving waar de leverancier die aanbiedt, zodat het eerste wat je echte administratie ziet een werkende koppeling is.

  4. 4. We dragen hem over met de faalgevallen opgeschreven

    Welke meldingen je krijgt, wat elke melding betekent, wat je eraan doet en wie je belt. Plus de inloggegevens op jouw naam, in jouw eigen kluis — niet in de onze. Een koppeling die niemand behalve wij kan onderhouden is een koppeling die niet van jou is.

Nadat hij live is

Een koppeling die stil faalt is erger dan geen koppeling

Dit is het deel dat in de meeste offertes ontbreekt. Een koppeling die stopt met werken zonder dat iemand het merkt is erger dan handwerk, want bij handwerk merkt iemand het tenminste als het niet gedaan is. Elke koppeling die JKC bouwt wordt gemonitord, en die monitoring is geen bijverkoop — die zit in de servicekosten.

Een melding per mislukt bericht, geen maandrapport

Een bericht dat niet doorkomt geeft binnen het uur een melding, met de regel waar het over ging. Geen dashboard dat je moet onthouden om te bekijken.

Opnieuw versturen, niet opnieuw invoeren

Wat mislukt is blijft in een wachtrij staan en kan opnieuw verstuurd worden zodra de oorzaak weg is, in de juiste volgorde. Niemand hoeft gisteren door te spitten op zoek naar de vier orders die niet zijn aangekomen.

Wij volgen de wijzigingen van de leverancier, zodat jij dat niet hoeft

API's krijgen nieuwe versies, worden uitgefaseerd en gaan op rate limits. Kondigt een leverancier een wijziging aan die jouw koppeling raakt, dan is meebewegen onderdeel van de servicekosten en geen nieuw project.

Wat het kost

Vanaf € 1.700, en de grootste variabele is wie de andere kant heeft gebouwd

Specifiek voor Jira: Data Center voegt een echt netwerkgesprek toe bovenop de gebruikelijke afbakening, net als bij een on-premise ERP — we regelen de route die jouw IT accepteert vóór de offerte, niet erna.

Een koppeling begint vanaf € 1.700 plus maandelijkse servicekosten, waar de monitoring, de wachtrij en het bijhouden van API-wijzigingen van de leverancier in zitten. Werk buiten een vaste scope is € 95 per uur.

Wat het bedrag beweegt is niet de tool — het is hoe goed het systeem aan de andere kant bekend is. Heeft JKC je website, je webshop of je webapplicatie gebouwd, dan kennen we het datamodel, de uitzonderingen en waar de voorraadaantallen echt vandaan komen, en is een koppeling erin vooral configureren en testen. Is het een systeem dat we nooit hebben opengeslagen, dan beginnen we met een korte technische check aan beide kanten en offreren we daarna, zodat je niet op uurbasis betaalt voor ons uitzoekwerk.

Twee dingen die het bedrag verder bewegen, in onze ervaring meer dan al het andere: of de tool een echte API heeft of alleen een CSV-export, en of de sync twee kanten op moet. Eenrichting is ruwweg de helft van het werk van tweerichting, want tweerichting betekent per veld beslissen welk systeem wint als ze het oneens zijn — en die beslissing is het dure deel, niet de code.

Vragen

Veelgestelde vragen over Jira koppelen

Beide, maar niet via dezelfde deur. Cloud is over internet bereikbaar met OAuth en de eigen REST API van Atlassian; Data Center staat meestal achter een firewall, dus een koppeling vraagt hetzelfde soort netwerkgesprek als een on-premise ERP — een VPN, een reverse proxy, of een programma binnen je netwerk dat gegevens naar buiten duwt. We vragen welke van de twee je draait vóór de offerte, want het antwoord verandert de koppelroute en niet alleen de prijs ervan.

Gratis, 10 minuten

Geen idee waar de handmatige uren echt naartoe gaan?

Daar is de Groeicheck voor. Tien minuten, zonder verkoopgesprek eraan vast: je krijgt terug waar het dubbele werk zit, welke koppeling zich als eerste terugverdient, en welke eerlijk gezegd niet.