Вспомним, что такое автоматизация. Возьмем, например, определение из Википедии.
Автоматизация — одно из направлений научно-технического прогресса, использующее саморегулирующие технические средства и математические методы с целью освобождения человека от участия в процессах получения, преобразования, передачи и использования энергии, материалов, изделий или информации, либо существенного уменьшения степени этого участия или трудоёмкости выполняемых операций.
Ключевую фразу я выделил жирным шрифтом. Проще говоря, автоматизация нужна для того, чтобы освободить человека от каких-то обязанностей. Что это такое – освобождение человека от обязанностей? Вы ведь слышали фразу «освобожден от исполнения обязанностей»? Это – увольнение.
Если вы занимаетесь автоматизацией, то скажите честно – много ли людей были освобождены от обязанностей благодаря вашей работе? Только здесь важны факты, а не домыслы.
К сожалению, или к счастью, такая цель автоматизации, как увольнение людей, или сокращение персонала, или перевод его на другие должности, несколько подзабыта. Проекты автоматизации, по факту, скорее создают новые штатные единицы, которые заполняются бухгалтерами, менеджерами, программистами, администраторами, экономистами, разного рода операторами и так далее.
Была, например, на заводе простая информационная система, созданная каким-нибудь умельцем. Для работы с ней требовался тот самый умелец, который ее развивал и сопровождал, и несколько пользователей. Но вот приходит в компанию амбициозный ИТ-директор и говорит – всё, пора заканчивать этот детский сад, надо выходить на новый уровень. И принимается внедрять большую, дорогую, сложную ERP-систему.
Стоимость продукта и проекта внедрения оставим в стороне. Очень быстро выясняется, что наш умелец в одиночку не справляется с сопровождением и внедрением – нужны новые люди, более современные, опытные и компетентные. Бухгалтеры, привыкшие к старой системе, тоже не годятся – привыкают медленно, данные своевременно не появляются, нужно расширять штат. Если раньше достаточно было вводить в систему десять видов операций, то теперь их стало пятьдесят – хотя результат, по факту, тот же самый. Система требует сложной настройки – вот и методист нам потребовался.
В службы, вроде производства и ПДО, теперь нужны операторы, как бы их не называли. Раньше справлялась одна женщина предпенсионного возраста, а теперь, в новом, более просторном кабинете, сидят уже три молодые девушки, и беспрестанно чего-то куда-то вносят и разносят.
Если кого и уволят в такой ситуации, то только нашего умельца и несколько пожилых сотрудников, не сумевших перестроиться. Разумеется, посадив на их место вдвое больше новых людей.
Большая автоматизация – не очень подходящее время для сокращения персонала. Намного лучше заняться целенаправленной автоматизацией такого рода в более спокойные времена.
Рассмотрим, как этот процесс организовать, на что обратить внимание и какие есть подводные камни.
Закон Паркинсона
«Работа занимает время, отпущенное на неё» — так формулируется этот шутливый эмпирический закон. Но, несмотря на долю юмора, он работает.
О законе Паркинсона следует все время помнить, когда вы занимаетесь увольнением через автоматизацию. Иначе ваш проект обречен на провал. Мне не очень часто приходилось автоматизировать для увольнения, и результат достигался. Но случаев, когда закон Паркинсона сводил усилия автоматизаторов на нет, в сотни раз больше.
Всё очень просто. Если у человека сто обязанностей, он будет целый день их выполнять. Если вы автоматизировали половину этих обязанностей, то оставшиеся пятьдесят он будет выполнять целый день. Доведете до десяти – он и их будет выполнять целый день. Человек найдет способ даже одну обязанность выполнять целый день.
Как ни парадоксально, но в любой из моментов времени будет казаться, что человек действительно занят, и свободной минутки у него нет. Если перед вами два бухгалтера, вы хотите (или вам поставлена задача) от одного из них избавиться, и вы автоматизировали половину их работы, то будьте уверены – бухгалтеры найдут массу оправданий и кажущихся вполне разумными объяснений того, что они вдвоем едва успевают выполнять оставшиеся обязанности.
Для того, чтобы избежать действия закона Паркинсона, нужно до выполнения автоматизации тщательно подготовиться.
Подготовка
Суть подготовки заключается в том, чтобы собрать максимум информации об обязанностях, выполняемых людьми. Речь именно о сборе информации – это, на самом деле, целый исследовательский проект.
Всегда существует, как минимум, три версии перечня обязанностей.
Первая – то, что скажет сам работник. Как правило, он расскажет, чем реально занимается.
Вторая – то, что скажет его начальник. Эта версия будет отличаться от первой. Во-первых, какие-то обязанности добавятся. Начальник думает, что подчиненный должен делать то-то и то-то, а работник об этом узнает только от вас. Но вам, после беседы с работником, будет что рассказать и его начальнику – тот узнает много новых обязанностей своих подчиненных.
Третья версия – то, что написано в различных должностных инструкциях, процессах, профилях должности, положениях об отделе и так далее. В бумагах, как правило, изложено то, что работник должен делать. Будьте готовы, что бумаги могут друг другу противоречить – это нормально, т.к. их составляли разные люди, в разное время и с разными целями. Не удивляйтесь, если и у работника, и у начальника округлятся глаза, когда вы расскажете о вычитанных обязанностях.
Есть еще вспомогательные версии – смежные отделы, внутренние потребители, более высокое руководство и т.д. Если позволяет время, изучите и их.
Принципиально, у вас получится два списка:
— Что работник должен делать;
— Что работник реально делает.
Сопоставив эти списки, вы получите три новых:
— Должен делать и делает (ДД);
— Не должен делать, но делает (нДД);
— Должен делать, но не делает (ДнД);
— Не должен делать и не делает (нДнД).
Последний пункт, вроде бы, кажется лишним, но далее я покажу, что и от него стоит ждать неприятностей.
Пополнение обязанностей
Итак, человек делает то, что изложено в первых двух списках – и то, что должен, и то, что не должен. Разумеется, автоматизацией этих обязанностей вы и займетесь. А работник, по мере сокращения этих списков, начнёт их пополнять – в соответствии с законом Паркинсона.
Как только объем выполняемой работы сократится до опасного минимума, человек просто начнет делать то, что раньше не делал. В первую очередь, возьмет что-нибудь из списка ДнД. Ему и объясняться особо не придется – версия будет звучать довольно правдоподобно. Я раньше этого не делал, потому что не успевал, а теперь вот занялся, спасибо вам за автоматизацию.
Если вы автоматизируете эти новоприбывшие обязанности, или вычеркнете их, то он продолжит таскать из ДнД в ДД, пока ДнД не опустеет.
Когда взять из ДнД будет уже нечего, возникнет парадоксальная ситуация – человек будет брать обязанности из нДнД. Проще говоря, начнет сам себе придумывать обязанности. Начнет активно помогать коллегам и внутренним потребителям, придумывать новые отчеты и формы, фонтанировать идеями, вступать в кроссфункциональные команды каких-нибудь проектов (в т.ч. вашего) и, наконец, активно участвовать в общественной жизни – петь, танцевать и создавать стенгазету.
Если потоком пополнения ДД и нДД не управлять, то он будет прирастать бесконечно.
Мораторий
Управлять потоком несложно – достаточно или наложить мораторий на пополнение, или применить «изолятор». Четко формализовать ДД и нДД, и не допускать появления в них новых пунктов. Разумеется, о моратории нужно сообщить, как минимум, начальнику этого человека.
Если есть возможность и время, то стоит переделать все бумажки, из которых вы составляли списки. Не обязательно своими руками – можно посадить начальника, или разработчиков бизнес-процессов.
Как вариант, можно использовать принцип «Пуля» из раздела «Мотивация». Объявите работнику, что он может заниматься чем угодно, но оплачивается только работа из составленного списка. Остальное – факультатив. Обычно такое объявление хорошо действует на выдумщиков обязанностей.
Что выбрать?
Дальше перед вами встает закономерный вопрос – а что именно автоматизировать из списка?
Первый вариант – выбрать, основываясь на своем опыте. Если вы хорошо знаете и предприятие, и процессы, и работу этого человека, то можно выбрать интуитивно.
Второй вариант – посчитать по формуле. Правда, потребуются измерения.
Главное, что надо оцифровать – процент времени на выполнение каждой обязанности. Интервалом измерений может быть день, неделя или месяц. Лучше, наверное, неделя, т.к. в течение конкретного дня выполняются не все обязанности из списка, а месяц – слишком длинный срок.
Достаточно простой метод измерений – фотография рабочего дня. Только желательно не доверять её составление самому сотруднику. Во-первых, он – лицо заинтересованное. Во-вторых, у него мало опыта для такой работы, и все равно придется за ним переделывать. Сделайте фотографию сами, или попросите помощников.
Фотография рабочего дня делается просто – нужно записывать на бумажку, что человек делает, когда начал и закончил. Далее нужно выполнить несложную обработку – сопоставить со списками ДД и нДД, сгруппировать и посчитать суммарное затраченное время на каждую обязанность. Ну и процент на каждую обязанность посчитать.
Теперь нужно оценить предполагаемые шаги по автоматизации, в разрезе обязанностей человека. Каждый пункт должен получить две оценки.
Первая – трудоемкость автоматизации. Подойдет любая числовая оценка – и часы, и баллы, и человеко-дни, не важно. Главное, чтобы были цифры. Из полученных оценок нужно вычислить долю каждого пункта в процентах.
Вторая оценка – предполагаемая степень автоматизации, т.е. процент времени, который высвободится у человека после внедрения изменений в информационной системе. Если операция автоматизируется полностью, и участие человека более не потребуется, то степень автоматизации будет равна 100 %.
Получив три оценки, вычисляем приоритет автоматизации по простой формуле:
Приоритет = С * ДВ / Т,
где С – предполагаемая степень автоматизации, ДВ – доля времени на исполнение обязанности, Т – трудоемкость автоматизации.
Т.к. все цифры у нас выражены в процентах, приоритет тоже будет относительным. Чем он выше, тем выше будет влияние автоматизации на освобождение человека от обязанностей. Можно выбирать и приступать.
Кроме относительных долей, неплохо бы иметь абсолютные цифры по времени выполнения обязанностей, чтобы избежать раздувания транзакций.
Раздувание транзакций
Человек, освобождаемый от обязанностей, умеет не только находить себе новые, но и раздувать старые, увеличивая время каждой транзакции.
Например, раньше на оформление накладной у бухгалтера уходило две минуты. Когда вы освободили его, например, от контроля отрицательных остатков, он станет оформлять накладную за пять минут.
Если у вас нет замеров времени «до» и «после», то вы даже не заметите, как транзакции расползутся и, согласно закону Паркинсона, снова займут все рабочее время сотрудника. Без цифр вы и доказать не сможете, что проблема имеет место.
Поэтому запаситесь цифрами. Желательно – до того, как о целевой автоматизации, направленной на увольнение, узнает сотрудник или его начальник. Подойдет и «Измеритель процессов» из бизнес-программирования, и данные логов, и статистика из множества программ, измеряющих время работы людей.
Вот вам пример. Работала в одной компании девушка-бухгалтер, и у нас были статистические данные о времени транзакций в ее работе. Девушка благополучно ушла в декрет, и начальник быстро нашел замену. Все ничего, но замена не справлялась, и взяли еще одну. Теперь две девушки выполняли работу одной и, что интересно, все равно не справлялись и вечно жаловались, что не успевают. Начальник попросил у директора еще одну ставку, и тот чуть было не согласился, но вспомнил о статистике. Сравнив данные транзакций, мы увидели – две новые девушки работают медленнее, чем одна старая. Штат раздувать не стали, хотя и на сокращение не решились.
И вот…
И вот настал тот момент, когда все цифры собраны, автоматизация выполнена, человека, объективно, можно освобождать. Конечно, его судьбу решать, скорее всего, не вам. Но, на практике, может случиться так: раз вы успешно его освободили, то к вашему мнению стоит прислушаться.
Поэтому я изложу некоторые варианты развития событий, чтобы вам было из чего выбрать.
Первое – просто увольнение. Тут, в общем-то, и рассуждать особо не о чем. Финансовый результат вашей работы просчитывается легко, и составляет весьма внушительную сумму, особенно если посчитать за год и не забыть добавить налоги.
Второе – перевод в другой отдел на аналогичную работу. Если компания крупная, то в балансе идентичных потоков часто встречаются перекосы. Например, есть два отдела снабжения – один по основным материалам, другой – по заказным, сложным или ВЭД. В одном всё хорошо, и именно там вы кого-то освободили, а в другом – завал. Если принципиальных различий в требованиях к компетенциям нет, то можно организовать перевод.
Третье – перевод на другую, хоть и схожую работу. Типичный пример – так называемые менеджеры по заказам, или проще говоря – операторы. Они есть и в снабжении, и в продажах, и в диспетчерских службах. Обычно это молодые, аккуратные и исполнительные люди, которых быстро учат, где брать информацию, что с ней делать и куда передавать. Сократив такого человека в снабжении, можно смело переводить его в продажи. Разумеется, если он нужен в продажах.
Четвертый вариант мне нравится больше всего – не увольнять, а «не набирать». Текучка в компаниях есть всегда, кто-то уходит на пенсию, кто-то – в декрет, некоторые просто увольняются по собственному желанию, иногда на повышение уходят.
Результат один – освобождается место. Если в этот момент у вас уже выполнена автоматизация, то достаточно никого на это место не брать. Причем, в этом варианте вы ничего особо не теряете. Прежний сотрудник все равно уже ушел, а нового вы всегда можете найти и принять, если будет завал.
Просто не берите никого и наблюдайте. Цифры у вас есть. Вы точно знаете, что оставшиеся сотрудники могут справляться со своей работой тем составом, который у них остался. Не давайте им расползаться и пополнять ДД и нДД, и все получится.
Этот способ можно комбинировать с переводами. Например, вы освободили сотрудника одного отдела, а перевести его некуда – везде под завязку. Что ж, ждем. Через некоторое время может уволиться сотрудник другого отдела, и вашего «освобождённого» можно переводить.
Из переводов, а точнее – вообще их наличия, как сущности, в компании – тоже можно извлечь пользу.
Во-первых, работа сотрудника в разных отделах обогащает его компетенции и понимание всей карты бизнес-процессов. Есть такие практики – для менеджеров, правда – когда их заставляют поработать в каждом отделе, чтобы лучше понять процессы и кроссфункциональные связи.
Во-вторых, эти самые кроссфункциональные связи улучшаются. Одно дело – замкнутые подразделения, варящиеся в собственном соку, со своими лидерами, скрытыми правилами и устоями. Совсем другое – по сути, проектная форма управления, когда сотрудник становится «свободным электроном» и притягивается туда, где он больше нужен в данный момент.
Ну и главное – вас не будет мучить моральная сторона вопроса.
Моральная сторона вопроса
Вопрос автоматизации для увольнения – тонкий и сложный. Сразу скажу – я не знаю, что здесь правильно, а что нет.
С одной стороны, увольняется ведь человек. У него есть семья, обязательства, кредиты, планы. Не нужно обладать большой фантазией, чтобы представить, какими плачевными последствиями может обернуться увольнение.
С другой стороны, есть бизнес. Если подняться на самую вершину, бизнес – тоже человек. Один, или несколько – не важно. Да, у них, скорее всего, больше денег, чем у сотрудников. Но это их деньги. Они создали бизнес не для того, чтобы платить чьи-то кредиты, реализовывать чужие планы или выполнять обязательства.
И вот она дилемма. Оставить сотрудника – значит, собственник будет платить ему собственные деньги. В нашем случае – по сути, ни за что. Уволить сотрудника – значит, создать вполне реальные, иногда опасные проблемы для него и его семьи.
Иногда в разрешении такой дилеммы помогает мысленный эксперимент. Представьте, что собственник – это вы, а сотрудники – это все обязательные платежи, которые вы осуществляете ежемесячно. Интернет, электричество, парковка, продукты, мобильная связь, бензин и т.д.
И вот, вдруг, вы узнаёте, что платите за интернет вдвое больше, чем нужно. Или тариф появился другой, или новый оператор пришел в ваш город, или вам вообще больше не нужен провод, достаточно безлимитного мобильного интернета. Конечно, если разница для вас невелика, то можно ничего не делать и оставить все, как есть.
А если разница значительная? Продолжите ли вы платить старому оператору вдвое больше только потому, что давно с ним работаете, или вам его жалко?
Или, например, вы узнали, что на вашей любимой заправке бензин дороже на два рубля, чем на другой, при аналогичном качестве топлива, обслуживания и программы лояльности. Будете ли заправляться и дальше на прежнем месте?
Каждый ответит на эти вопросы по-своему. В общем случае, речь о небольшой экономии. Так же и для большого предприятия один работник – не очень заметная обуза. Но не забывайте, что сумму можно посчитать за год, и рассмотреть через призму своего годового бюджета. Хотя, повторюсь, каждый решает сам.
Решили вы, например, что переключитесь на другого поставщика интернета. А что будет с прежним провайдером? Особенно, если не только вы, но и все ваши соседи поступят аналогично? Вполне ведь вероятно, что кого-то уволят, для сокращения расходов, или вообще бизнес разорится? Есть вам до этого дело?
Скорее всего – нет. Вокруг нас постоянно создаются и умирают бизнесы. Год назад в соседнем доме был магазин мяса, через полгода его сменила кальянная, а месяц назад въехала пекарня. Почему они закрываются? Стандартный ответ – не идёт дело, не покупают. Кто не покупает? Если магазин в соседнем с вами доме, значит – вы? Почему не покупаете? Не нужно, или дорого, или не вкусно? Но вы ведь понимаете, что если не будете отдавать этому магазину деньги, то он закроется, и всех его работников уволят? Но покупать-то не будете. Значит, моральная сторона вопроса не так важна.
Еще раз повторю: лично я – против увольнений. Мысленный эксперимент привел только для увеличения точек обзора. На сотрудников и их увольнение все смотрят по-разному, и это нормально. Нет единой точки зрения, как нет и правильной.
Моя личная, если интересно: усилия надо прилагать для того, чтобы не нанимать лишних людей, а не на их последующее увольнение.
Наём работника – это ответственность. Если взял человека, то он на тебя надеется, строит планы, связанные с доходами и перспективами твоей компании, берет на себя обязательства – ту же ипотеку. Поэтому лучше трижды подумать, прежде чем кого-то нанимать. И попробовать повысить эффективность работы текущего штата.
Ну а если уж сложилось так, что человек стал лишним, не увольнять его, а перевести.
Примеры из практики
Для полноты картины приведу и удачные, и неудачные примеры.
Работают на складе два бухгалтера, оформляют операции по отгрузке, приходу, перемещению и т.д. Формально один – бухгалтер, второй – экономист. Ставят задачу – автоматизировать так, чтобы остался один.
Посмотрел их обязанности, оказалось очень немного. Кроме оформления первичных документов, еще стандартное для бухгалтера участие в закрытии месяца, выполнение разовых поручений, вроде массового исправления проводок, ну и большая серая масса «чего-то там еще бывает делаю».
Вводим мораторий – оформляете только первичку, и всё с этим связанное. Серую массу игнорируем – оказалось, что ее особо-то и нет. По первичке делаем несколько простых доработок – заполнение автоматическое и по шаблонам, ввод на основании, бумажки перетряхнули (там местами требовались ручные корректировки перед выводом на печать). На все работы – не больше месяца.
Ту девушку, которая экономист, тут же и уволили. Я был против, конечно – экономиста было чем занять – но, почему-то, вариант оставить ее даже не рассматривался.
В бухгалтерии было еще несколько девушек, только сидели они в офисе. Выполненная автоматизация по вводу первички настолько снижала время транзакций, что закономерно поднялся вопрос об увольнении и оставшегося бухгалтера. Руководитель был настроен решительно, но на этот раз удалось выполнить перевод – я как раз начинал проект по наведению порядка на складе, и мне требовался изолированный человек, вот эта девушка и пригодилась.
Кстати, потом руководитель сильно радовался, что не уволил девушку – она стала очень толковым специалистом. Это она – та, которая работала быстрее, чем две новых.
Потом был неудачный пример. Поговорил с офисными бухгалтерами, и нашел у них два низко висящих фрукта для автоматизации. Первый – закрытие месяца. У них использовался партионный учет в 1С, который отнимал значительное время при выполнении регламентных операций.
Для тех, кто не знает, немного проясню. Есть месяц, и в нем несколько тысяч транзакций – приходы, расходы, перемещения и т.д. При использовании партионного учета каждый документ зависит от всех предыдущих – в первую очередь, по стоимости списания. Технически это означает, что при изменении документа от 15 мая нужно перепровести все документы с 15 по 31 мая. Это не сложно, но очень долго. А изменений надо было вносить достаточно много. И вот каждый раз – изменил, и перепроводишь. Днем, ночью, синхронно, асинхронно – не важно, все равно долго.
Но потом в 1С появилась расширенная аналитика учета затрат (РАУЗ), которая проблему перепроведения снимала полностью – оно не требовалось вообще. Изменил любой документ – надо лишь выполнить процедуру закрытия месяца, тогда это занимало минут 5-10.
Вот этот переход с партионного учета на РАУЗ дал экономию по срокам закрытия – примерно 7 дней.
Второй проблемой были учет и сверка бумажных и электронных документов. В те времена электронный документооборот не был распространен, и в ходу были одни бумажки. Пришел груз, с ним бумажки, их берет менеджер или кладовщик и тащит бухгалтеру. Тот вбивает, и вроде всё хорошо, но менеджеры частенько бумажки теряли. Ну, не то чтобы теряли, но найти не могли.
А бумажки, зачем-то, периодически требовались налоговой. Главная проблема, по сути – отсутствие информации, какие бумажки у нас есть, а каких нет. Несложная автоматизация проблему решила – появился учет бумажек в привязке к электронному документу.
Так вот, по утверждению бухгалтеров, до начала автоматизации, возня с бумажками отнимала у них 20 % времени. Я тогда не вспомнил про закон Паркинсона, кинулся автоматизировать, проблему победил, но 20 % времени, естественно, куда-то растворились. Я ведь даже не удосужился списки составить – ни ДД, ни нДД. Поэтому никого не уволили и не перевели.
Дальше были экономисты. С ними проще – у них транзакций немного, в основном – регулярные задачи, вроде предоставления отчетов. Даты и количество отчетов известны, осталось лишь автоматизировать.
Отчеты у экономистов сложнее, чем у бухгалтеров, а главное – они все исполнялись не по каким-либо общепринятым стандартам, а так, как принято в компании и удобно получателям. Поэтому шаблоны и образцы были только в экселе.
Особую трудность в автоматизации доставляло качество данных. Собственно, на проверку, а точнее – выверку данных у экономистов уходило больше всего времени. Берут сырые данные, вставляют в эксель, и погнали проверять, сводить, анализировать и т.д.
С качеством данных справились достаточно быстро, применив методы «Проверка при записи» и «Асинхронная проверка». Потом нарисовали отчеты – по чистым данным они строятся быстро.
Настал момент принятия решения. Экономистов было трое, все плюс/минус равны. Недолго думая, решили никого не увольнять, а подождать подходящего случая.
Случай представился довольно быстро – один из экономистов уволился, по каким-то своим причинам. Обрадовались и не стали никого брать на его место. Понаблюдали – отлично, справляются.
Через некоторое время уволился второй экономист, вроде по политическим причинам – то ли с кем-то поругался, то ли что-то не поделил, точно не знаю. Обрадовались, не стали никого брать на его место. Понаблюдали – справляется один экономист. Так и оставили.
Были несколько однотипных примеров, когда выполненная автоматизация и наличие цифр по транзакциям спасали от расширения штата бухгалтерии. Инициатива «дайте мне еще одного бухгалтера» не является наказуемой, поэтому проявляли ее часто, и новые главбухи, и старые, выдержав некоторую паузу после предыдущей попытки.
Алгоритм стандартный. Приходит главбух, просит добавить единицу и приносит какое-то обоснование – обычно без единой цифры, просто набор предложений вроде «у нас стало больше работы», «обороты растут, мы не справляемся» и т.д.
Статистика по транзакциям велась постоянно, поэтому проверка проходила быстро. Оказывалось всегда одно и то же – количество транзакций не выросло, иногда даже снизилось, сложность оформления документов тоже не изменилась, существенных изменений в законодательстве и процессах не произошло. Просто закон Паркинсона действует, и время на транзакцию растет.
Иногда просто отказывали в расширении, иногда выбирали компромисс – делали какую-нибудь автоматизацию, чтобы снизить время транзакции, ну а иногда решение принималось политическое – поддержать нового главбуха, тогда штат расширялся.
Ну и напоследок пример, который примерно прямо сейчас происходит. Есть предприятие, изготавливающее продукцию на заказ. Эта продукция уходит на другие заводы, где входит в состав конечных изделий, поставляемых клиентам.
Заказов много, они сложные по расчетам, и всегда уникальны. Сколько существовало предприятие, столько и сидели там менеджеры, принимающие эти заказы. Собственно, в приеме заказов и сопутствующей деятельности и состоит вся их работа – принять, внести в систему, выписать счет, отправить в производство, проконтролировать оплату, выписать документы на отгрузку.
Сделали мы им сервис для самообслуживания клиентов, с несложным интерфейсом для заводов-клиентов. Те пристроили сервис к своим системам – и 1С-ным, и php-шным, и еще черт знает каким. Снабженец в своей привычной системе просто оформляет заказ поставщику, как он и делал много лет, а данные автоматически улетают нашему клиенту, там за секунду рассчитываются, формируется заказ, с ценами, спецификацией, датами производства и отгрузки – в общем, вся необходимая информация создается. Даже счет на оплату самому себе распечатать можно.
Менеджер, по сути, больше не нужен. Одного-двух оставить, для общего контроля и решения спорных и аварийных вопросов, и всё, остальных смело можно увольнять или переводить. Но все друзья на месте.
Причина простая – мы выполняли этот проект, работая только с автоматизацией. Ровно так, как это делают большинство программистов – получили задание, сделали, запустили и забыли. Никаких фишек бизнес-программирования, вроде процессов, системы управления, целей и т.д. А должны были работать, как бизнес-программисты.
Ну и чего, казалось бы? Нам же заплатили за этот проект.
Проблема в том, что клиент никакого профита не получил. Сидели у него менеджеры без сервиса, и справлялись с потоком заказов. Теперь справляется сервис, а менеджеры все равно сидят. С точки зрения руководителя и собственника никаких изменений не произошло. Только деньги зря отдали за разработку.
Собственно, этот пример должен хорошо показывать разницу между программированием и бизнес-программированием.
Мы, конечно, надежды не теряем, и ищем пути, на которых наша автоматизация будет выполнять свое прямое назначение – освобождать людей. Чего и вам желаем.
