Внедряване на софтуер в търговията: какво ме научи едно двумесечно ERP внедряване

Първата бизнес система, която внедрих, построих на деветнадесет години, сам, за около два месеца. Поглеждайки назад през двадесет години внедрявания, почти нищо от това, което направих правилно през онези два месеца, не беше свързано с кода.

Компанията разпространяваше вестници и списания през над петдесет павилиона в един град. Доставки, наличности, връщания, склад, работа с пари в брой и разчети с доставчици, и всичко това при продукт с брутално кратък търговски живот. Вестникът губи стойността си по-бързо от млякото и всеки процес в този бизнес беше оформен от този факт.

Бях единственият програмист. Системен администратор ме научи как да разбивам задачата и как да държа кода в някакъв ред. Всичко, свързано с внедряването — да говоря с хората, да променям начина им на работа, да накарам системата да бъде приета — научих, като грешах пред публика.

Петдесет павилиона, два месеца и никаква представа колко е неразумно

Задачата беше да взема съществуваща софтуерна основа и да я разширя, докато покрие операциите, наличностите и паричния поток в цялата компания. Онова, което ме впечатлява днес, е как се държеше изпълнителният директор. От първите разговори говореше с деветнадесетгодишен за бизнес процеси, за това как отделите си предават работата, къде засяда информацията и какво според него може да се организира по-добре. Не спецификации. Бизнесът.

Част от причината това да проработи не е ласкателна: не знаех достатъчно, за да разбера, че задачата е неразумна. Опитен мениджър щеше да направи оценка на риска, да напише план, да поиска екип и да обясни защо два месеца са почти невъзможни. В много случаи щеше да е прав. Неразбирането на мащаба на един проблем понякога дава енергия, която правилно калибриран човек никога не би похарчил.

Да не знаеш колко неразумна е една задача може да е истински източник на енергия. Но не е план и не оцелява при срещата с втория обект.

Писано през нощта, тествано сутринта

Методът, ако заслужава тази дума, беше следният: пиша парче през нощта, сутринта го давам на реални служители, които вършат реална работа, наблюдавам го през деня, намирам изискването, което съм пропуснал, и започвам отначало. Когато свършвах, спях в сървърното помещение, поддържано на осемнадесет градуса, което на тази възраст се понася. Не го възприемах като пилотно или поетапно внедряване. Наричах го: код през нощта, пускане сутринта, поправки през деня.

Години по-късно прочетох работата на Хакман и Олдъм от 1976 г. за това как дизайнът на работата поражда мотивация: автономия, видим резултат, усещане, че работата има значение, и незабавна обратна връзка. Имах и четирите по случайност, защото нямаше кой друг да ги има. Разстоянието между решението и последствието му беше няколко часа, а обратната връзка идваше от хора, които трябваше да живеят с това, което съм пуснал. Рядко беше дипломатична и никога не беше грешна.

Това е най-силният аргумент, който познавам, за държане на хората по внедряването близо до работата. В по-големите компании, в които работих после, отделите, предаванията и нивата на одобрение разтегнаха това разстояние до седмици, а качеството на обратната връзка се разваляше по целия път.

Защо героизмът спира да работи на втория обект

Системата тръгна и продължи да води отчетността на бизнес с над петдесет павилиона и няколкостотин търговци на едро. Получих бонус от 300 долара и го похарчих за велосипед, което на деветнадесет е защитимо разпределение на капитал. Работата продължи и след пускането: логика за зареждане, генериране на поръчки към доставчици, препоръки за отписване на връщания и накрая складов модул, който казваше на хората къде да отидат. Дойде втори програмист и станах ментор, без да имам представа как се прави това.

Оттук идва и корекцията, която бих дал на деветнадесетгодишния. Личната отговорност изнася първия проект забележително далеч, а после спира. Никоя организация не бива да зависи от готовността на един човек да се лиши от сън. Трябва да се превърне в процес, документация, знание, което държат повече хора, и системи, които работят без спасяване. Свързаната теза конкретно за слоя на отчитането, че не може да бъде специфициран веднъж и оставен с години, е темата на защо стекът ви за отчети вече не може да бъде еднократен проект.

Въпросите, които показват, че внедряването е сработило

Изкушението е внедряването да се съди по това дали е спазен планът и колко чиста е инженерната част. Архитектурата има значение и лошата архитектура рано или късно става бизнес проблем, само че по по-бавен часовник. Но един технологичен екип не може да се оценява само по това колко добре е организирал собствения си процес. Ето въпросите, които задавам вместо това, месец или два след пускането:

• Наистина ли спадна честотата на грешките и вижда ли се това в данните, а не само във впечатленията?
• Хората свършват ли същата работа по-бързо, или работата просто се е преместила при някой друг?
• Мениджмънтът получава ли същата информация по-рано, или само в по-красив формат?
• Наличностите по-разбираеми ли са, отколкото бяха, по обект, категория и период?
• Кои ръчни стъпки изчезнаха напълно и кои само смениха собственика си?
• Промени ли се някакво бизнес решение заради системата и можете ли да го назовете?

Ако нито един от тях няма отговор, системата е пусната. Това не е същото като внедрена, а разстоянието между двете е мястото, където се губят повечето пари в такива проекти.

Софтуерът става част от работата, а не инструмент до нея

Работата на Ерик Трист върху социотехническите системи, по-стара от почти целия софтуер, за който спорим днес, го казва по-добре, отколкото бих могъл аз. Новата система не заменя само инструмент. Тя променя отношения, кой какво решава, как се разпределя отговорността, колко хората вярват на това, което гледат, и за какво в крайна сметка спорят.

Ако хората не вярват на данните в основата, не могат да проследят защо системата препоръчва нещо или прекарват част от всеки ден в поправянето ѝ, щетата вече е излязла от софтуера и е влязла в работните отношения около него. Появата на AI изостри този аргумент, вместо да го омекоти. Препоръка, която никой не може да провери, е проблем на доверието, преди да е проблем на потребителското преживяване.

Какво пренесохме в marql

marql е слой над POS, счетоводните и e-commerce системите, които една търговска верига, ресторантска група или франчайз мрежа вече използва, само за четене и хостван в ЕС. Не заменя POS или ERP и не записва нищо обратно в тях, което е съзнателен избор колко от една организация има право да разклати едно внедряване наведнъж.

Ангажиментът, който поемаме, е нарочно тесен: квалифициран преглед на стека, първи изглед на живо до 24 часа и цени от 200 EUR на месец. Бихме предпочели обаче да ни съдят по списъка по-горе — дали оперативният ръководител получава отговор по-рано от преди и дали това променя нещо. Конкретен пример как изглежда това, когато едно число тръгне накриво, има в как да разследвате липса в наличностите.