Hallom, ahogy felsikítanak páran: “Már megint Design Thinking? Már a csapból is ez folyik!” És igen, míg ez lett szerintem az elmúlt év egyik buzzwordje, amit naponta lehetett kipipálni a céges bullshit bingón, az néha lemaradt mellőle, miért is fontos tulajdonképpen a Design Thinking, és mire lehet ezt használni akár a cégen belül is.
Aki esetleg újonnan érkezik a Design Thinking fanklubba, a rövid definíció a Stanford d.school szavaival: “A design thinking egy módszertan kreatív problémamegoldásra”. Egy módszertan olyan helyzetekre, ahol egy problémára keressük a megoldást. Bárhol bármire használható akár az üzleti életben, akár az oktatásban vagy akár cégen belül. Alapvető hasznos információkat lehet a d.school honlapján találni teljesen ingyenesen, akár saját gyorstalpaló kurzus anyagokat is találtok (lásd a d.school Resources szekcióját).
Ha viszont valós példát néznénk inkább, hadd osszak meg pár helyzetet, ahol érdemes lehet Design Thinking megközelítést használni egy szervezeti környezetben:
Az első példa probléma: A cégen belül nem hasít a sales. Vannak mutatószámok és elvárások, de azt figyeltük meg, valahogy a valós eladási eredmények mindig elmaradnak a tervtől. Ez tehát a “problem statement”.
Mire jó itt a Design Thinking: Ahelyett, hogy rögtön ötletelnénk, akkor mit csináljunk másképp, a Design Thinking módszertannal először a helyzetet próbáljuk megérteni, feltárni, mi lehet a háttérben, beszélgetünk valós emberekkel, kollégákkal, ügyfelekkel, és nem feltételezésekből, hanem az ő elmondásukból és adatokból próbálunk meg következtetéseket levonni.
Jelen esetben: Tegyük fel, a beszélgetések eredménye az lett, azért nem mennek jól az eladások, mert a sales-esek között sok újonc van, és ők nem értenek még mindenhez a portfólióban olyan mértékben, mint a tapasztalt rókák. Kapásból másképp hangzik ez a probléma, nem, mint az első volt? Ha az elsőre ráugrunk, és rögtön terméket fejlesztünk vagy mutatókat variálunk, más eredményre jutottunk volna, mintha először megértjük, hol is van a valós probléma, jelenleg a csapat tapasztalatlanságában és képzettségében.
Ha tehát innen indítunk a fejlesztéssel, a sales csapat, a vezetőség, akár egy adag segítőkész ügyfél bevonásával tudunk fejlesztési, megoldási lépéseket kitalálni, hogyan lesz rutinosabb a sales csapat, mi kell ahhoz, hogy az eladások fellendüljenek a segítségükkel.
A második példa probléma: Bevezettünk a cégen belül egy tök jó új projektmenedzsment szoftvert, tud mindenféle csilli-villi funkciót, de nem akarják a kollégák használni, továbbra is inkább saját gépen, Excelben kezelnek projekteket. Így senki nem látja, min dolgozik a másik, nem tudunk közösen erőforrásokat és prioritásokat kezelni. Ez tehát a “problem statement”.
Mire jó itt a Design Thinking: Ha már az látszik, hogy a kollégákra van a megoldás hatással, ők kellene, hogy másképp dolgozzanak, mint eddig, akkor hasznos, ha beszélgetünk velük és megtudjuk, a) mire van szükségük, hogy a projekteket átláthatóan tudjuk kezelni, és b) mi kellene ahhoz, hogy használják az új szoftvert, amit bevezettünk. Persze a helyzetünk sokkal, de sokkal egyszerűbb lenne, ha az új megoldás bevezetése előtt tettük volna mindezt. Mert akkor rögtön beépíthettük volna, mire van a valós felhasználónak szüksége a cél elérése érdekében. Így azonban utólag tudunk ezen segíteni a Design Thinking segítségével.
Jelen esetben: Beszélünk a kollégákkal, akik kérték az eszközt, akik tervezték, akik fejlesztették, akik használnák, mi volt az elképzelés, mire jó a tool, milyen problémára ad választ, és azt is meg kell tudnunk, mi kell ahhoz, hogy a felhasználó kollégák elkezdjék használni, nekik mire lenne szükségük. Ezekből a tanulságokból fogunk tudni levonni következtetéseket, mi volt az eredeti probléma, amire az eszközt bevezették, mi a mostani probléma, ami miatt nem használják, és hogyan tudunk ebből mind jól kijönni: legyen a probléma is megoldva, és a kollégák is értelmes szoftvert vagy folyamatot kapjanak a kezükbe, hogy lássák, van értelme váltani, használni.
Ebben az esetben kapunk sok ötletet a kollégáktól, és azok megfontolásával valós igények alapján tudjuk fejleszteni a megoldást a valós problémánkra. Így mindenki jól jár: egyrészt látszik, ennél a cégnél érdemes hozzáadni a véleményemet, mert van foganatja, szeretnének javítani, ami motiváló, másrészt az új megoldást is szívesebben fogom használni, mert van értelme, harmadrészt a cégnek is jó, mert a kollégák elkezdik használni az új megoldást, ami növeli a projektek követhetőségét, a priorizálást és az erőforrás kezelést.
Próbájátok ki, csak egy probléma kell hozzá. Egészen hétköznapi helyzetekre is gondolhattok: gyakran a mosogatóba pakolnak a kollégák a mosogatógép helyett, vagy gyakran foltos lesz a padlószőnyeg, amikor sietnek a kollégák a cégen belül kávéval a kezükben. Vagy túl hosszú a release management ciklus a céges gyártástervezés szoftverre. Vagy van egy bottleneck a kiszállításban valahol, és a délután 4 után gyártott termékek mindig késnek 23 percet a csomagolóterületen. Vagy kellene egy új mező a céges CRM szoftverbe, mert kódokat szerenénk beleírni a hírlevelekkel kapcsolatban. A kollégák pedig örülni fognak, hogy végre valaki az ő szakértői véleményüket is meghallgatja, és még a végén olyan megoldás születik, ami mind a vezetőségnek mind a kollégáknak előnyös.
Vendégszerző: Laczkó Katalin - IT és általános menedzsment szakember. Az informatika mellett kiemelten foglalkozik vállalati digitális transzformáció be- és végigveztetésével. Fontos számára a nők helyzete az IT-ban, személyes célja, hogy ledöntse a sztereotípiákat ezen a területen. A szerző cikkei: Mit ne felejtsünk el, ha digitális transzformációra készülünk?, Hogyan tervezzük meg az új évet?
Képforrás: freepik.com