Обичайната последователност е: избира се инструмент, инструментът се настройва, и после се надяваме, че процесът ще се нагоди към него. Това на практика не работи, защото инструментът не носи процес с себе си. Инструментът носи полета, връзки, табла — но не и въпроса кой във вашата организация носи отговорност за енергийното потребление на сграда три, или дали фасилити мениджърът, който предоставя това число, знае, че то ще влезе в отчета за обхват 2.
Правилната последователност е обратната: първо се описва процесът, после се избира инструмент на база това, от което процесът има нужда. Това звучи като обиколен път, но е най-краткият маршрут, защото всяко функционално изискване, което поставяте към инструмент, трябва да произтича отнякъде от собствената ви организация на данните. Без тази отправна точка избирате въз основа на функции, които доставчик смята за важни, не функции, които решават вашето затруднение.
Разходите от грешната последователност не се виждат веднага, защото инструмент, който не се вписва, в началото работи чудесно — за частта от процеса, която случайно съвпада с това, което инструментът очаква. Останалото се изгражда ръчно около него: приложение в Excel тук, размяна на имейли там, служител, който знае точно коя стъпка остава извън системата. Това работи, докато този служител не напусне или обемът на данните не нарасне.
Колко ще ви струва, зависи от колко точки от данни минават извън инструмента и колко често трябва да се събират отново ръчно при всеки отчетен цикъл. При малък брой точки това е приемлив обиколен път. При растящ брой — повече локации, повече категории от обхват 3, повече законодателство, което се включва — обиколният път се превръща в основния маршрут, и вие плащате структурно за несъответствието между инструмента и процеса. Това е друг начин да се каже това, което стои и на тази страница: инструмент върху неорганизиран процес произвежда по-спретнати отчети върху същите ненадеждни числа.
Функционалното изискване е изискване едва когато произтича отнякъде. „Инструментът трябва да може да показва произход на данните“ не е изискване, докато не знаете, че вашият контролер трябва три пъти годишно ръчно да издирва откъде идва едно число. „Инструментът трябва да може да фиксира собственост“ не е изискване, докато не сте видели, че точка от данни без собственик не стои в списъка със задачи на никого.
Това е точно причината, поради която регистърът на точките от данни, произходът от източник до отчет за всяка точка от данни и разпределянето на собствеността трябва да съществуват първо, независимо от кой инструмент накрая ще изберете. Щом тези три неща са на хартия — коя точка от данни, откъде идва, кой се подписва за нея — имате списък с изисквания, който не идва от доставчик, а от собствената ви организация. Този списък използвате за сравняване на инструменти, не за да изберете сляпо някой от тях. Как да подходите към това сравняване без последващо разкаяние, е описано на тази страница за избор на инструмент.
Мястото, където се намират данните, силно се различава по сектор, а това определя и кои функционални изисквания са релевантни. В строителна компания голяма част от данните за устойчивост се намира при подизпълнители и на самата строителна площадка, както е описано на тази страница за източниците на данни в строителството; там изискване, свързано с множество външни източници на проект, вероятно е по-важно отколкото в други сектори. В инсталационния бранш данните по-често са разпръснати между сервизни бонове и регистрации на материали на ниво проект, както може да се прочете на тази страница за инсталационния бранш; там най-важно е дали инструментът може да обединява разделни точки на въвеждане, без някой да прави това ръчно.
Общият въпрос — първо да се настрои процесът или първо да се купи инструмент — е доразработен на тази страница, а основният въпрос на тази страница, кои изисквания точно произтичат от собствения ви процес, е обобщен на тази страница. Двете страници тръгват от една и съща точка: последователността определя дали изискване е изискване, или е гадаене.
Data Readiness Scan фиксира регистъра на точките от данни, произхода и собствеността, преди да се говори за инструмент. Това не е инструмент за отчитане и не е решение с въпросник — това е стъпката, която определя какво всъщност трябва да може инструмент за вашата организация. Без тази стъпка купувате функции; с тази стъпка купувате решение за проблем, който можете да посочите.
Сканирането е в процес на изграждане. Който иска процесът му да бъде картографиран по този начин, преди да се направи избор на инструмент, може да се запише в списъка на чакащите и ще бъде информиран, щом сканирането стане достъпно.
Щом регистърът на точките от данни е готов и е ясно от какъв източник произтича всяка точка от данни и кой носи отговорност за нея, се появява втори, естествен въпрос: коя част от работата около това — събирането, проверката и пренасянето на числа — все още е човешка работа, и коя част може да поеме система, без надеждността да намалее. На този въпрос отговаря работния скенер на FTE TO AI, който за всяка задача изчислява коя част от работата може да бъде поета от AI. Това е различен скенер от Data Readiness Scan, и логично негово продължение: първо да се знае какви са данните и откъде идват, после да се погледне коя част от ръчната работа около тях може да отпадне.
Vraag maar waar een datapunt vandaan komt. Dat is meestal de hele vraag.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.