Если вы ждёте, что пост закончится рекламой какой-то системы, то сорян пацаны, простого решения в этом вопросе не существует, и по прочтении вы поймёте почему.
Считается, что каждый собственник предприятия и его топ-менеджеры хотят, чтоб предприятие работало как швейцарские часы. На самом деле нет, но признаться в этом они чаще всего не могут даже самим себе, а уж окружающим не сознаются даже под слабыми пытками. Но об этом позже.
Пока что примем за аксиому, что наладить работу мечтают все ЛПР (лица, принимающие решения).
Пофиг, какую систему управления предприятием выберут мозганы в руководстве, очень быстро они сталкиваются с необходимостью внедрять какую-то компьютеризированную систему управления предприятием. Люди ошибаются, а компьютер нет. Люди задалбываются делать рутинные проверки, а компьютер нет. Люди не могут делать несколько дел одновременно (про Цезаря и женщин - пиздеж), компьютер может. Люди могут забыть что-то сделать и просрать дедлайн, компьютер нет.
Ну, тут я с ними соглашусь. Любые автоматизированные или полуавтоматизированные помощники в бизнесе - это круто. Их тоже можно использовать во вред, но тут уж приходится вспомнить поговорку про дурака, которого заставили богу молиться. В хороших руках любая компьютерная система помощи управления предприятием - как экзоскелет солдата будущего. Только экзоскелет увеличивает физические возможности, а Система - возможности профессиональные.
И вот топ-менеджеры и собственник начинают напрягать свои умища и рассматривать разные системы. Приезжают продавцы, устраивают презентации. Выбор на рынке огромный. От икс тысяч рублей (1С) до миллионов долларов (SAP R3).
Какая система самая лучшая?
А никакая.
Мне случалось видеть, как на предприятии три года строили систему на базе SAP R3 и в итоге получали какое-то унылое говно, которое настолько мешало работать, что работники делали в ней операции только необходимые по регламенту, а реальную рабочую инфу пересылали друг другу по электропочте или даже звонили друг другу по телефону. Случалось мне видеть и обратное - кто-то из говна и палок собирал прекрасно работающую систему (правда, в небольшой фирме, потому что в огромной так не получится).
Часто бывает забавная ситуация - топы при посещении вражеского предприятия увидят охеренно работающую систему, и у них срабатывает карго-культ: нам такую же надо!!! Заказывают аналогичную систему, а в итоге получается снова УГ. В чем секрет?? А все просто.
Сразу оговоримся о главном. Есть разные виды систем: СЭД (система электронного документооборота), ERP (enterprise resource planning system - система управления ресурсами предприятия), системы управления складом, логистикой, кадрами (HRMS) и так далее. К ним ко всем применимо правило Эскобара - что то хуйня, что это хуйня. Это все одни и те же яйца, которые за каким-то хером назвали по-разному.
Для меня есть Система, а что в ней делается - вопрос уже второй. По-хорошему на предприятии нужно автоматизировать всё или почти всё. В реальной жизни так получается редко, поэтому чаще всего автоматизируют только ту часть, которую видно топам. Если за плохую работу склада топов премии не лишают, то и автоматизация склада будет проводиться в последнюю очередь.
Возвращаясь к вопросу «да как же блять сделать-то хорошую систему?» Отвечаю. Чтобы сделать хорошую Систему, необходимы три составляющих:
1. Охуенный аналитик, который знает всю работу предприятия и сможет написать волшебное ТЗ. Это может быть и кто-то из топов, кстати.
2. Охуенный программист.
3. Воля руководства.
Как вы заметили, во всех трёх пунктах не сказано, какую систему выбрать. Выбирать надо ту систему, по которой у вас есть охуенный программист. Ну, система должна минимально подходить под ваши нужды, надеюсь, это очевидно.
Если охуенного программиста нет, то смиритесь, что получится унылое говно, даже если 1 и 3 будут выполнены.
Чем делать отвратительно работающую дорогую кривую и косую систему, лучше взять что-то пусть даже примитивное, и усовершенствовать процессы.
Я как-то видел систему, написанную одним талантливым чуваком на экселе. Для небольшой фирмы, несколько десятков человек, но зато система была идеально подогнана под нужды этой конторы, и работала как швейцарские часы.
От безысходности в одной конторе я организовал годный документооборот и управление ресурсами, вы будете смеяться, на базе электронной почты. Каждая операция сопровождалась письмом, написанным по определенному шаблону, и отправленным определенному кругу лиц.
Самую крутую систему из виденных мной, чоуштам скромничать, сделал я, на базе презираемой всеми 1Ски. Секрет был в том, что ее писал пряморукий программист, и она была ёбаным совершенством. Тогда сошлись вместе все три фактора - я видел систему полностью и мог сформулировать требования сразу ко всем частям, программист талантище реализовывал все мгновенно и очень качественно, а собственник компании не просто декларировал, что поддерживает нас, но и на самом деле крышевал нас полностью.
Перейдём к пункту (1).
Что такое охуенный аналитик? Это чувак, который хорошо знает предприятие и знает, чего можно ожидать от разных людей, работающих в разных департаментах.
Вигерс в своей главной книге (гуглите, если не знаете) называет такого человека product visionary. Кстати, в русском переводе переводчики не поняли о чем идёт речь, и перевести вообще не смогли, написали «специалист по компьютерному зрению».
Если в компании нет такого человека, который в голове держит всю систему, то аналитики разработчика начинают собирать требования с руководителей департаментов, и в итоге создают чудовище Франкенштейна, слепленное из плохо подходящих друг другу разнородных частей (задроты есть в комментах? Подскажите, как там правильно звали чудище, которого все ошибочно называют Франкенштейн, а на самом деле это имя создателя чудища).
Разные части плохо друг с другом коннектятся.
Какой-то департамент вносит в систему данные, которые никуда не попадают.
Какой-то департамент, наоборот, получает в работу что-то от другого департамента, но не может двигаться дальше, потому что предыдущий департамент не внёс в систему какие-то необходимые данные.
Какие-то одни и те же данные вносят с разных сторон разные департаменты, и данные нередко различаются. Первый департамент ожидает увидеть в системе свои цифры, не зная, что их уже изменил другой департамент, в итоге у них нихуя не сходится «итого», на поиски ошибки тратят выходные и миллионы нервных клеток, «Иван Грозный убивает своего сына» и всё такое.
Ещё один необходимый для product visionary скилл - умение строить открытые системы, когда не только вся система готова к подключению каких-то новых блоков в будущем, но и каждый блок системы строится таким образом, что в нем заложена возможность развития до более глубокой степени автоматизации без необходимости перестройки фундамента.
Поясню. Никогда не бывает такого, что изначально написали подробное ТЗ, за полгода-год запилили по нему идеальную систему, и работают в ней без изменений хотя бы год.
Если предприятие размером хоть немного больше ларька с паленой водкой, то пока вы пишете ТЗ и пилите систему, процессы на предприятии могут нехило измениться - откроются новые цеха, прикупят смежный бизнес, выйдут на принципиально новые рынки сбыта и так далее. А система нужна уже прямо сейчас, и некогда допиливать ее до идеального состояния. Поэтому приходится работать «с колес» - делать какой-то минимально жизнеспособный продукт, и к нему постепенно пристраивать новые блоки.
Выбирается самый сложный участок, где автоматизация нужна наиболее остро, пишется блок автоматизации, а всех смежников автоматизируют по минимуму.
Например, автоматизируем производство, а смежников - например, склад компонентов, склад готовой продукции, логистику автоматизируем по минимуму. То есть склад готовой продукции вручную забивает цифры «какие компоненты есть на складе», получает цифровые заявки от производства, отгружает ему компоненты, но работа склада в остальном не автоматизирована.
И вот тут очень важно, чтобы product visionary мог написать ТЗ с возможностью поэтапной реализации разных блоков без необходимости начинать делать каждый блок сначала. То есть так, чтобы когда руки дойдут до автоматизации склада, программист не охреневал от необходимости менять фундамент системы. И чтобы работники склада не охреневали от того, что в какой-то день их автоматизированное рабочее место полностью изменилось. В какой-то момент у них просто в АРМе просто буду появляться новые поля для ввода данных, их работа будет автоматизироваться, становиться проще и спокойнее.
Product visionary должен понимать возможности системы и логику ее работы. А то в России нередко автоматизация выглядит как «те же самые бумажные документы, только в отсканированном виде».
Поясню на своём любимом примере из Айн Рэнд. Там герой книги, Хэнк Риарден, металлопромышленник, изобрёл сплав, по стоимости, скажем, как Ст3, а по свойствам (прочность и легкость), скажем, как титан.
Пытается продать первому заказчику на строительство моста, а главный инженер заказчика утверждает, что мост из нового сплава будет не сильно дешевле моста из традиционной стали, применяемой для металлоконструкций.
Но Риарден объясняет заказчику, что классическое проектирование учитывает большой вес конструкций, из-за чего значительная часть конструкций моста тратится на то, чтобы «держать самих себя». Если же строить из его нового, легкого и прочного сплава, конструкции можно делать гораздо более легкие, и мост окажется почти втрое дешевле.
https://mir-knig.com/read_418283-55
Ну и перейдём к самому нереализуемому пункту (3). Воля руководства. Со стороны может казаться, что топ-менеджеры только и мечтают сделать работу на предприятии прозрачной и понятной. По факту они в этом почти никогда не заинтересованы.
На предприятии сложился некий статус кво, при котором у каждого топа есть своё место под солнцем. Любые изменения могут выкинуть кого-то за борт. Да и уровнем ниже всегда есть множество личностей, которые много лет «ловят рыбку в мутной воде», и они тоже будут изо всех сил сопротивляться автоматизации, которая наверняка выведет их делишки на чистую воду.
Подробнее я писал об этом тут.
Ну и напоследок.
Не мечтайте внедрить коробку. Часто схема продажи выглядит так. Приходит заказчик к интегратору, описывает, какую он хочет систему. Интегратор говорит «8 миллионов и полтора года». Заказчик хватается за голову «да вы что?? Мы рассчитывали на 300 тысяч, и от силы пару месяцев». Продавец делает ход конём - «Берите коробку <такой-то стандартный пакет> за несколько сотен тысяч рублей, а там настроите под себя, мы вам учебник дадим».
Заказчик покупает, ебется несколько месяцев с настройками, понимает, что не получается, через полгода-год смиряется с доп расходами, платит миллион-другой интегратору, интегратор чего-то там пилит, но результат так себе. Так, методом салями (когда требуемый результат отрезается по кусочкам) интегратор вытягивает из заказчика еще немного денег.
В итоге заказчик обнаруживает, что потрачено уже больше 8 миллионов, времени ушло 4 года, а система далека даже от того образа, который описывали в самом начале сотрудничества. А тут за 4 года аппетиты только выросли, и новых хотелок от всех департаментов насыпалось немеряно.
Так что делайте сразу хорошо. Нет денег на крутую систему - делайте на базе дешевой системы, без прибамбасов, но чтоб то, что есть, помогало в работе и экономило вам деньги. На сэкономленные деньги уже можно будет строить серьезную систему, которая вообще, может быть, половину работы за людей делать будет.
Подытожим.
Для создания хорошей автоматизированной системы управления предприятием необходимы три ингредиента:
1. Product visionary - человек, который будет видеть работу предприятия целиком и работу системы в целом.
2. Очень крутой программист (или несколько, если вы строите реально огромную систему).
3. Реальная воля руководства.
