Автоматизация – это не перевод бумажного потока документов в «цифру», или как не просто быть новатором. Взгляд неоавтоматизатора на существующие на Российском рынке парадигмы.


Аватар пользователя Дмитрий Агеев

Написать данную заметку меня побудило долгое наблюдение (с 2003г.), и че уж греха таить и участие, в качестве компании разработчика, на рынке программных продуктов для транспортно-логистических компаний. Все что описано ниже — является исключительно личным мнением автора. Если обобщать, то рынок программного обеспечения идет вслед за реальным сектором экономики. Растет экономика – растет и рынок программного обеспечения, меняется экономическая ситуация – меняются и требования к ПО. Если оглянуться назад не в 90-ые а в 2000-ые, то можно заметить несколько закономерностей. В принципе они касаются всего рынка программного обеспечения, но в данной статье мы коснемся только программного обеспечения для транспортно-логистических компаний. Ниже привожу наиболее характерные стадии развития рынка транспортно-логистических услуг и типичные для данной стадии требования к программному обеспечению и автоматизации бизнеса: • Транспортно-логистический рынок дикий — поле непаханое, конкуренция практически отсутствует. Самое начало деятельности. Требования к программному обеспечению и автоматизации бизнеса – практически отсутствуют. Да какие там требования и так все хорошо. Ведем учет в экселе. • Рынок дикий поле еще большое, конкуренция есть но не ощущается. Растут объемы деятельности, обороты, увеличивается штат. Эксель уже не справляется, теряются данные, решается все созданием новых и новых таблиц под разные аспекты деятельности. Приходит понимание, что нужна учетная информационная система, которая бы позволяла работать одновременно большому кол-ву пользователей. — Требования к автоматизированной информационной системе просты – что бы учитывала. Как правило требования ограничиваются контролем взаиморасчетов – первичная задача не терять деньги. Задача решается, как правило, принятием в штат программиста, которому в свободной форме ставится «задача», эффект достигается далеко не сразу т.к. задача ставится фрагментарно и программист в бизнесе не ориентируется. Информационная система проектируется от документов и строиться на базе существующего документооборота. • Рынок более зрелый, появляется конкуренция, у компаний появляется специализация. Объемы уже не растут дикими темпами, больше внимания уделяется внутренним процессам. Требования к автоматизации расширяются, появляются требования по автоматизации рутинных и массовых операций, как правило это касается автоматизированного создания документов и их печати. Информационные системы по прежнему являются калькой существующего на предприятии документооборота. • Рынок устоявшийся, количество игроков на рынке достигло предела, обострилась конкуренция, маржинальность прошлых периодов только снится. Нужно повышать эффективность транспортно-логистической деятельности и снижать непроизводительные издержки, за клиентов приходится бороться. Требования к автоматизации, несмотря на явные изменения на рынке изменились мало – максимально дешево, и что б учитывало. Единственно что добавляется – желание найти некий типовой программный продукт, который можно было-бы установить и сразу начать работать. Это, к сожалению, утопия! Единственная сфера, где это желание резонно и достижимо, это — бухгалтерский, налоговый и кадровый учет, которые все компании, в не зависимости от отрасли и сферы деятельности, обязаны вести в жестком соответствии с единым частоколом законодательных требований. Вернемся к требованиям к автоматизации, принципиально новых требований не предъявляется т.к. нет прецедентов автоматизации не только документооборота и учета, но и повышения коммерческой эффективности деятельности компании за счет снижения издержек. Почему об этом никто не задумывается? Потому что на рынке ИТ услуг прочно закрепилась парадигма автоматизации документоборота и построения информационных систем «от документов». И рамками этой парадигмы зажаты и как сами компании нуждающиеся в информационной системе как в инструменте повышения эффективности, прежде всего коммерческой, так и поставщики ИТ услуг (вендоры). Вот эту ситуацию и разберем подробней. Итак, немного раскрою термин «построение информационной системы от документооборота предприятия». Если предприятию требуется информационная система, то как правило происходит следующая ситуация. Приходит вендор — проводит обследование, «так, какие документы у Вас создаются – ага понятно, в какой последовательности, на основании каких других документов, какие отчеты требуются – все ясно, вот Вам ТЗ в котором прописана последовательность создания документов в системе, и выходные формы отчетов». Понятно, что я привожу все несколько утрировано, и ТЗ включает в себя больше информации, но общий принцип действительно таков и извините «тупиков». В результате разработки такой информационной системы заказчик не получит ничего, кроме возможности вести учет по факту. Не будет прогноза узких мест своих процессов, не появится — фактного анализа, о прогнозировании останется только мечтать! Управление останется на уровне пост-фактум, как сокращать свои издержки если событие уже произошло, как повышать рентабельность, если процессы остались неизменны? Почему спросите Вы??? Ответ очевиден! Любой документ является результатом или выходом уже какого-то произошедшего бизнес-процесса, повлиять на который уже нельзя! Можно конечно после этого провести анализ и попытаться сломать «систему», но где гарантия что в этом случае причины потерь будут истолкованы верно? Как же быть – с одной стороны все довольно очевидно, строить информационную систему или программный продукт от бизнесс-процессов и принять за постулат, что документы вторичны, не в том смысле что они не важны, вовсе нет, но являются следствием происходящих в компании процессов. С другой стороны – такой подход существенно «усложняет жизнь» вендору т.к. гораздо проще автоматизировать регистрацию конечного документа, чем реализовывать различные варианты, комбинации и взаимосвязи бизнес-процессов, которые приводят к созданию этого документа. Т.е. получается документ один – но вариаций бизнес-процессов в результате которых он создается гораздо больше. Яркий пример – счет покупателю, понятная стройная форма документа с четким и конечным набором данных, но что ей предшествует, какая масса вопросов должна быть решена в системе, что бы счет покупателю был выставлен не в убыток, вовремя и с нужной рентабельностью, здесь все очень сильно зависит от процессов компании. И именно поэтому автоматизация бизнес-процессов гораздо сложней автоматизации документооборота. Если мы ставим цель не только автоматизировать документооборот — а действительно повышать рентабельность компании, даже при неизменных объемах услуг, то нам нужен инструмент (программный продукт) который позволяет влиять на процессы компании до того как они произошли т.е. позволять планировать эти процессы, на основании запланированных процессов прогнозировать узкие места, которые появляются в результате планирования, вносить изменения в планы что бы этих узких мест избежать, отслеживать отклонения фактических показателей процессов (как финансовых так и временных) от планируемых и вновь по кругу. Только так и никак иначе! Так почему-же подход «от бизнес-процессов» так редко встречается на отечественном ИТ рынке ? Ответы ниже: 1. Во первых к этому подталкивают сами компании – требуя по дешевле, в то время как процессный подход (назовем его так) требует объективно больших временных и ресурсных затрат со стороны вендора т.е. проект разработки и внедрения «процессной» информационной системы будет объективно дороже и дольше. 2. Во вторых – процессный подход требует другой проектной технологии в которой больше проектных этапов и одним из самых главных является моделирование, когда вендор и заказчик прописывают как будут осуществляться процессы компании с участием информационной системы, ТЗ разрабатывает позже, основываясь исключительно на материалах моделирования. 3. В третьих – от вендора требуется понимание и не шапочное, бизнес-процессов заказчика, понимает отрасли, бизнеса расходов и доходов заказчика, понимание того где заказчик теряет деньги. Согласитесь – это серьезные требования, которые требует от вендора определенной отраслевой экспертизы, которая на ровном месте никогда не возникнет, ее наработка может занимать годы. 4. В четвертых – компании не ставят перед вендорами задачи снижения издержек и повышения рентабельности в результате внедрения информационной системы т.к. относятся с ПО как к затратной части, никто не воспринимает автоматизацию – как инвестиции. 5. В пятых – растерянность компаний перед лицом полноценного проекта по адаптации отраслевого решения под их особенности т.к. стоимость подобного проекта является весьма существенным довеском к стоимости программного продукта. Оказывается, недостаточно просто приобрести права на использование, необходимо работать над его внедрением, вдумчиво работать в связке с вендором . 6. В шестых – отсутствие на рынке законченных процессно-ориентированных решений для транспортно-логистических компаний. Вот тут можем вас обнадежить. Компания SeaData успешно решила эту задачу. Мы разработали программный продукт SeaExpediter 2.0, в котором воплощен именно процессно-ориентированный подход к автоматизации. Ирония нашего положения в том, что старые взгляды на использование информационных систем настолько крепки, что главной нашей миссией мы скоро будем считать донесение до наших клиентов отличий данного решения от других учетных и документно-ориентированных программных продуктов. Итак – ситуация весьма не простая. Рынок информационных систем для транспортно-логистических предприятий по прежнему не самый передовой, транспортно-логистические предприятия не относятся всеръез к проектам, не готовы формировать иновационные требования, тратить на них средства с целью получения конкурентных преимуществ, после их реализации. Со стороны вендоров, нет опережающих предложений для отрасли – нет желания разрабатывать (за свой счет разумеется) что-то принципиально новое, «зачем? итак 100 раз уже купили». Рынок пестрит массой коробочных «типовых» продуктов, которые содержат результаты заказных проектов для какого-то из заказчиков отрасли, с унаследованным подходом «от документов», окончательно запутывая тех кто пытается найти для себя «рабочий инструмент» ведения и развития бизнеса. В следующий раз я поделюсь своими наблюдения о том, какой путь в автоматизации является передовым и на мой взгляд наиболее продуктивным, с точки зрения эффекта от автоматизации, того самого profit’а Купрашевич Юрий Директор и продукт менеджер компании SeaData