Бывает так, что жизнь подбрасывает задачи, которыми ты вовсе и не собирался заниматься, когда проектировал свою систему документооборота. Можно, конечно, гордо сказать «наша система для этого не предназначена» и это будет вполне честный профессиональный ответ. А можно трезво подумать, как использовать возможности ЕСМ по-новому и рискнуть выйти за границы отведенной себе ниши – и заказчика удовлетворить, и новый опыт наработать.
Если ECM-система была спроектирована с хорошим запасом гибкости и адаптивности, то область ее применения можно безбоязненно расширить на многие смежные задачи, выходящие за рамки канцелярского документооборота. Автоматизировать процесс МТО – материально-технического обеспечения, посягнув при этом на традиционную поляну ERP? А почему бы нет, если заказчик того просит?
Суть проблемы
Мы живем в такое время, когда уже невозможно найти службу или подразделение в крупной организации, куда бы не ступала еще нога айтишника. Конечно, отдел МТО в нефтедобывающей компании САНЕКО (дочернее общество НК «Альянс») тоже был когда-то автоматизирован – там стояла отдельная 1С и жила своей автономной жизнью, никак не сопрягаясь с общекорпоративной учетной системой также на 1С. Закупщики принимали от подразделений заявки в Excel-файлах, заносили данные к себе и дальше обрабатывали по известным им процедурам. Для остальных система была черным ящиком – чтобы получить информацию о состоянии заявки, нужно было спрашивать отдел закупок.
Как это обычно бывает, разработчика той заказной конфигурации 1С для управления закупками давно и след простыл. А между тем появились новые требования, изменились процессы, потребовалась интеграция с документооборотом… Собственно последний фактор и сыграл решающую роль, потому что при работе в двух системах неизбежно происходило дублирование информации и нужно было от этого избавиться.
Процесс МТО: откуда берутся заявки и что с ними происходит
Процесс материально-технического обеспечения начинается с потребности. Когда сотрудник подразделения знает, что ему нужно закупить, он формирует заявку и включает в нее нужные позиции. По сути заявка – это своего рода контейнер для множества позиций к закупке. Например, заявка на канцтовары может включать ручки, блокноты, степлеры и так далее.
Подготовленная заявка отправляется в отдел закупок, там ее при необходимости оценивают и возвращают инициатору, чтобы тот мог посмотреть вписывается он в бюджет или нет. Далее, когда плановая стоимость позиций примерно известна, начинается согласование заявки, при котором она проходит через разные службы и окончательно утверждается. Маршрут согласования определяет делопроизводитель отдела МТО, к которому попадают все заявки от подразделений-инициаторов. Он же проверяет правильность оформления заявки и отнесения ее к статьям расходов.
Утвержденная заявка возвращается в отдел МТО на исполнение, где назначается ответственный за нее сотрудник. Вот здесь начинается самое интересное: позиции внутри заявки могут перегруппировываться, можно консолидировать заявки от разных подразделений или разбивать заявку на несколько частей. В итоге, на основе всех позиций, включенных в заявки, формируется план поставки. Потом проводятся тендеры, определяются победители, с которыми заключаются договора, которые также проходят согласование в СЭД. Заявка считается исполненной, когда инициатор получает заказанные им позиции.
А почему бы все не сделать на 1С?
Вроде бы логично было все учетные задачи решать на одной платформе – раз в организации основная учетная система построена на 1С, то и процессы материально-технического обеспечения автоматизировать в ней же. Но как всегда, важное в деталях. Дело в том, что корпоративная 1С внедрена на уровне холдинга и поддерживается централизованно в Москве, и в ней нет закупочного модуля. К тому же, это не коробка, а сильно кастомизированное решение, заточенное под НК «Альянс» и ради одной дочки вносить изменения в общую систему никто не стал бы. Сохранять же «островок автоматизации» в виде 1С в отделе МТО заказчик абсолютно был не настроен.
С другой стороны, в САНЕКО уже был внедрен электронный документооборот на ТЕЗИС, в том числе управление договорами. Концепция бизнес-процесса МТО подразумевала, что договор на закупку должен быть согласован с инициатором, а это логичнее делать в СЭД, чем в учетной системе. Потом финальная версия договора должна выгружаться в «большую» 1С, где она принимается бухгалтерией к учету.
Чисто теоретически, задачу автоматизации процессов МТО можно реализовать преимущественно как средствами ERP, так и средствами ECM, перенося тяжесть разработки на одну или на другую систему, а обмен данными обеспечить путем их интеграции. Но поскольку мы говорим не о сферическом коне в вакууме, а о конкретном заказчике, то вариант с модернизацией 1С даже не рассматривался. Да и какой смысл пускать в бухгалтерскую систему множество пользователей, которые инициируют и согласуют заявки? Пусть они это делают в документообороте и не лезут в финансы.
Экспертиза в предметной области – дело наживное
С технической стороны новая задача выглядела сложной, но решаемой: добавить в систему новый тип документов, новые маршруты, дописать бизнес-логику. В общем-то ничего необычного – если есть хороший постановщик, эксперт в предметной области. Понятное дело, что в компании, которая занимается внедрением СЭД внутренней экспертизы по процессам МТО не было. Зато на стороне заказчика нашлись люди, знающие свою тему и готовые рискнуть выступить в качестве бизнес-аналитиков.
По сути, обе стороны это делали в первый раз, вместе набивали шишки и вместе росли на этом проекте. Разумеется, можно было позвать бизнес-консультантов, которые бы объяснили, как надо правильно строить процесс и как его автоматизировать, но это, во-первых, изрядно бы увеличило бюджет проекта, а во-вторых, не факт, что непременно привело бы к успеху. Главные приоритеты были ясны: избавиться от устаревшей неподдерживаемой системы и построить сквозной бизнес-процесс МТО на основе успешно работающей СЭД ТЕЗИС, причем сделать это за разумные деньги.
Посмотрев доступные на рынке коробочные решения, было обнаружено, что хоть формально они и решают задачу, но это сделано так неудобно, что едва ли можно было заставить людей этим пользоваться. В общем, невзирая на все страхи и риски, решили писать систему управления закупками на СЭД ТЕЗИС.
Как это делалось
Проект стартовал летом 2012 года. Чтобы не шокировать пользователей нововведениями, запланировали постепенный переход от старой системы к новой. Сначала мы добились, чтобы заявки создавались в ТЕЗИСе, а не пересылались в виде файлов по почте. На первом этапе их выгружали в старую 1С в полуавтоматическом режиме, но поскольку при этом возникало раздвоение баз – какие-то заявки уже шли в ТЕЗИСе, какие-то доходили свой путь в 1С, то это было тяжело для пользователей. Поэтому к новому году надо было полностью отказаться от старой системы, чтобы не затягивать переходный период. Что, собственно, и было сделано – после нового года полностью перешли на работу в ТЕЗИС, и 1С можно было похоронить.
Не имея экспертизы в предметной области у нас не было возможности управлять заказчиком, говорить, что им надо реально, а что можно отбросить, находить нестыковки в требованиях. Поэтому приходилось их слушать и делать что просят, а заказчик, со своей стороны, постепенно начинал мыслить системно. В результате только через пару месяцев «совместной жизни» начало приходить осознание, какая информация действительно нужна и как это должно выглядеть в системе. Однако, несмотря на эти трудности, сроки проекта удалось выдержать.
Нетиповой проект – стимул к развитию продукта
Часто бывает, что фичи, запрошенные заказчиком в нетиповом проекте потом плавно перетекают в основной продукт, таким образом способствуя его развитию. Что касается автоматизации процесса МТО, то в принципе штатных возможностей платформы вполне хватило и не пришлось изобретать каких-то радикальных новшеств. То есть, наших средств управления документами и бизнес-процессами оказалось достаточно и для задачи из новой предметной области, что не могло не порадовать.
Пожалуй, разве что с отчетами пришлось повозиться – нужно было сделать аналитическую справку, когда формируется такая большая простыня-«шахматка» с динамическими колонками и строками, которые растут в зависимости от данных. Этого наша платформа CUBAтогда не умела и по итогам проекта в САНЕКО мы отчетность подтянули.
В целом же, можно сделать такой вывод: если у нас есть нормальный BPM и добротный модуль управления документами, то можно браться за любые подобные учетные задачи.
Что нам дает новое знание?
Если продавцы слышат, что появилось новое решение, они сразу думают «вот сейчас мы быстренько это перепродадим другим клиентам, потом коробку выпустим…» Но к сожалению, все не так просто – быстрой монетизации новых знаний может и не произойти.
На самом деле когда берешься за новый проект, то получается, что много вкладываешься чтобы понять вообще, о чем это, как в этом бизнесе все устроено. И становится жаль потраченного времени, если в итоге получается какое-то бесполезное, невостребованное знание. Куда его потом употребить? До коробки доводить сложно, конкурировать в лоб с ERP-системами глупо. Но в данном случае было ценно само понимание, что мы можем это сделать, что наша платформа позволяет реализовать такие задачи, достаточно далекие от обычного документооборота.
Заказчики все время возникают разные – а такие проекты дают уверенность, что потенциально любую задачу можно решить. В управлении предприятием закупки и финансовая деятельность считаются одними из самых сложных процессов, потому что они включают взаимодействие между большим количеством пользователей, причем не просто в режиме согласования, а подразумевают активную работу с информацией, консолидацию, какую-то ее обработку и т.д. Благодаря таким проектам, есть уверенность, что мы готовы и к более крупным и сложным задачам.
Начать дискуссию