Продолжаем серию статей на тему "СЭД: путь от простого к сложному".
Можно ли при помощи СЭД автоматизировать контроль казначейской деятельности в компании, у которой подразделения и дочерние организации находятся на большом удалении друг от друга? Это смотря какая у вас СЭД. Сразу оговоримся: речь не идет о том, чтобы все бизнес-процессы свести к перекладыванию «бумажек» и смоделировать работу всех подразделений по принципу канцелярии. Отнюдь!
Дело в том, что узко-предметный подход к разработке бизнес-приложений, в том числе и СЭД, давно в прошлом. Сегодня любая приличная система обладает изрядным запасом гибкости и функциональности, поэтому может быть использована для решения порой нетипичных задач. Так и получилось в вертикально-интегрированной нефтяной компании НК «Альянс», где, ввиду интенсивного документооборота и необходимости организовать эффективное взаимодействие между пользователями из разных регионов России и Казахстана, выбор СЭД ТЕЗИС в качестве платформы оказался более чем успешным.
Для справки: Казначейство — это одно из ключевых подразделений обычно холдинговой организации, координирующее работу всех финансовых служб дочерних обществ и подразделений. Основной задачей данной финансовой структуры является обеспечение бесперебойного движения денежных средств как с внешними контрагентами, так и внутри организации.
Каждый платеж – это событие, транзакция, которую нужно обсчитать, согласовать и исполнить. То есть, это некий документ (или пакет документов), который должен пройти по определенному маршруту согласования и исполнение его должно быть проконтролировано. Звучит очень похоже на постановку задачи на внедрение СЭД, не так ли? Только сам документ специфический – не какая-то там служебная записка, а сложный объект, с вычисляемыми по определенным бизнес-правилам полями и обменивающийся данными с другими системами. То есть, здесь мы немного забираемся на поляну ERP.
В НК «Альянс» использовалась обособленная система бюджетирования, не устраивающая заказчика. Мы на тот момент работали с организацией и уже успешно внедрили систему документооборота ТЕЗИС. В ее составе есть весьма приличный инструментарий для управления бизнес-процессами и конструктор сущностей, унаследованный от CUBA (платформа, на которой написана СЭД ТЕЗИС). Таким образом, можно создавать свои собственные типы объектов и задавать регламент их обработки. А функции раздачи поручений и контроля в принципе инвариантны относительно предметной области, поэтому наш опыт из СЭД оказался вполне применим.
Золотое правило «работает – только ничего не трогай» применимо до определенного предела, пока люди готовы терпеть неудобства старой системы и не видят других реальных альтернатив. В нашем случае было два раздражающих фактора:
И еще (это обнаружилось уже на внедрении): Во время опытной эксплуатации готовились отчеты в двух системах, старой и новой. В одном из отчетов нашли расхождение. Естественно, объявили это багом новой системы. Однако, когда все тщательно проверили вручную, пришлось признать, что это ошибка старой системы.
ОК, все программисты ошибаются, бывает. Но одно дело ошибки логические, которые можно выловить на этапе тестирования и другое дело ошибки из-за ненадежной архитектуры: то, что хорошо работает для одного пользователя не всегда удачно масштабируется в распределенной многопользовательской среде.
В старой системе бюджетирования возникали проблемы вследствие использования режима совместного редактирования таблиц – такой механизм ввода первичных данных был предусмотрен, но при этом трудно контролировать целостность данных. В ТЕЗИС все транзакции сразу идут через сервер, и подобная коллизия просто не может произойти.
Крупную организацию невозможно автоматизировать при помощи одной единственной системы, навесив на нее все задачи – такова правда жизни. Обязательно найдутся задачи, для которых функциональный заказчик потребует внедрить какое-нибудь особенное решение, а потом извольте обеспечить сквозные бизнес-процессы! Интеграторов это, безусловно, радует, а ИТ-службу заказчика – далеко не всегда.
Но что совершенно недопустимо по современным меркам, так это наличие «островков автоматизации» – обособленных систем, которые невозможно включить в общий контур обмена информацией. НК «Альянс» столкнулся как раз с такой ситуацией: система, используемая на тот момент казначейством, была полностью обособлена – не взаимодействовала ни с бухгалтерией, ни с СЭД.
Поэтому трезво поразмыслив, заказчик решил сократить число систем и отказаться от прежнего решения, переложив его функциональные «обязанности» на ТЕЗИС. С архитектурной точки зрения, такое упрощение ландшафта есть несомненное благо. Если задачу можно решить меньшим числом систем, обязательно надо так делать.
Пока бухгалтер не создаст платежное поручение в своем 1С и не отправит эту платежку в банк, деньги никуда не уйдут, будь ваша заявка хоть трижды согласована и утверждена. Если вы принесете ее в бухгалтерию на бумаге или даже пришлете как документ по электронной почте, вам придется ждать, пока бухгалтер забьет ваши данные в свою систему. А этих заявок тьма-тьмущая.
Вам же, как всегда, нужно срочно, да? Так помогите бухгалтеру, заполните платежку сами. Не умеете работать в 1С? Понятно… Так же и бухгалтеру не хочется изучать лишние системы. Поэтому чтобы никого не напрягать, решили все процессы согласования заявок вынести в ТЕЗИС, а благодаря проверенным механизмам интеграции с 1С, реализовать взаимодействие компаний в холдинге.
«Так в 1С есть и документооборот!» – скажет внимательный читатель. И он будет прав, но заказчик получил негативный опыт с этим продуктом на другом проекте, и не хотел вновь рисковать. А история с ТЕЗИС развивалась вполне положительно – система документооборота уже была в промышленной эксплуатации.
В итоге все инициаторы платежей сами делают в ТЕЗИС заявки на оплату (в большинстве по шаблонам), на основе которых формируются платежки в 1С, а бухгалтеру достаточно их просто проверить, а не набивать с нуля.
Допустим, технические возможности системы позволяют вам делать что угодно – хоть документооборот, хоть казначейство, хоть семечками торговать – на базаре или на бирже. Гибкость – 100%. Сущность и процессы – какие угодно. Но почему же мы видим, что компании, даже оснащенные универсальным инструментарием, очень медленно проникают в новые предметные области? Потому что в любом деле нужно наработать экспертизу, прежде чем станет все легко получаться.
Заявка на оплату– это не обычная служебная записка, у которой есть лишь номер и дата. Во всяком новом деле есть нюансы, поэтому приходилось и переделывать продукт по мере уточнения требований и накопления знаний.
Вот, например: сначала сделали по-простому – одна заявка – одна бюджетная статья. Оказалось, что это не совсем удобно, потому что одна заявка может проходить по разным статьям, например, когда в рамках одного договора вместе с каким-то товаром идут услуги по его установки/внедрению.
С учетом ежемесячного финансового планирования, на основе которого в конечном итоге и формируются заявки на проведения платежей, возможность гибко работать с этим самым платежами крайне важна. Реализованная система контроля казначейской деятельности на базе СЭД Тезис позволила сократить время по работе с финансовыми заявками за счет возможности формирования единой заявки, которая сначала включается в финансовый план, а затем сразу после подписания первичных документов отправляется на согласование к оплате, что довольно типично в 90% случаев.
Сотрудники финансовых служб в свою очередь получили возможность разбивать заявку на несколько платежей, переносить их между месяцами и осуществлять более низко-уровневое планирование при помощи платежного календаря.
В целом команда ТЕЗИС успешно справилась с проектом. На основе СЭД была построена система автоматизации работы казначейства в крупном холдинге, которая обеспечивает работу с бюджетом движения денежных средств, проверку лимитов, согласование и планирование платежей, отслеживание фактов оплаты.
Заказчика полностью устроило новое решение. Как это часто бывает, какое-то время в процессе внедрения пользователям приходится параллельно работать в двух системах, а поскольку люди консервативны, то новое порой приживается с трудом, под административным нажимом. В НК «Альянс» этого не произошло. (Опять-таки по причине того, что автоматизация казначейства по сути была расширением функциональности СЭД.)
Географический фактор часто рушит самые правильно написанные планы, а удаленное общение не всегда компенсирует живое. И здесь тоже все было успешно. Судите сами: функциональный заказчик в Москве, разработчик в Самаре, а внедрения по всей России. При этом потребовалось всего две командировки – на запуск проекта и на сдачу. Остальное время общались удаленно, однако весьма интенсивно, даже побили все рекорды в компании заказчика по длительности конференц-коллов по Skype. Конечно, сэкономили на командировках, но есть еще один момент: пользователями должны были стать высокопоставленные сотрудники финансовой службы, которые всегда очень заняты – можно было бы ловить возле кабинетов их целыми днями, зря тратя время своих аналитиков, тогда как разговор по Skype мог быть запланирован на удобное для всех время.
Реализуя задачу управления казначейством, мы фактически вторглись на территорию ERP со своей СЭД системой. Это стало возможным благодаря универсальной платформе CUBA, и в принципе нет архитектурных и технических препятствий, для того, чтобы разработать на этой платформе полнофункциональную ERP.
Подводя черту, можно сделать вывод:
Имея в руках СЭД, в основе которой лежит универсальная гибкая платформа, можно ввязываться в самые разнообразные проекты, далеко выходящие за рамки традиционного документооборота. Риск связан не с технической стороной, а исключительно с компетенцией в предметной области.
Конечно, СЭД не заменит ERP или CRM, чтобы довести кастомное решение до уровня продукта, придется много поработать – и это будет уже другая история. Если кто-то возьмется – welcome! Стоппером здесь может быть только недостаток соответствующих компетенций в предметной области.
Историю этого проекта и отзывы заказчика можно прочитать тут.
Можно ли при помощи СЭД автоматизировать контроль казначейской деятельности в компании, у которой подразделения и дочерние организации находятся на большом удалении друг от друга? Это смотря какая у вас СЭД. Сразу оговоримся: речь не идет о том, чтобы все бизнес-процессы свести к перекладыванию «бумажек» и смоделировать работу всех подразделений по принципу канцелярии. Отнюдь!
Дело в том, что узко-предметный подход к разработке бизнес-приложений, в том числе и СЭД, давно в прошлом. Сегодня любая приличная система обладает изрядным запасом гибкости и функциональности, поэтому может быть использована для решения порой нетипичных задач. Так и получилось в вертикально-интегрированной нефтяной компании НК «Альянс», где, ввиду интенсивного документооборота и необходимости организовать эффективное взаимодействие между пользователями из разных регионов России и Казахстана, выбор СЭД ТЕЗИС в качестве платформы оказался более чем успешным.
Казначейство – это обработка заявок
Для справки: Казначейство — это одно из ключевых подразделений обычно холдинговой организации, координирующее работу всех финансовых служб дочерних обществ и подразделений. Основной задачей данной финансовой структуры является обеспечение бесперебойного движения денежных средств как с внешними контрагентами, так и внутри организации.
Каждый платеж – это событие, транзакция, которую нужно обсчитать, согласовать и исполнить. То есть, это некий документ (или пакет документов), который должен пройти по определенному маршруту согласования и исполнение его должно быть проконтролировано. Звучит очень похоже на постановку задачи на внедрение СЭД, не так ли? Только сам документ специфический – не какая-то там служебная записка, а сложный объект, с вычисляемыми по определенным бизнес-правилам полями и обменивающийся данными с другими системами. То есть, здесь мы немного забираемся на поляну ERP.
В НК «Альянс» использовалась обособленная система бюджетирования, не устраивающая заказчика. Мы на тот момент работали с организацией и уже успешно внедрили систему документооборота ТЕЗИС. В ее составе есть весьма приличный инструментарий для управления бизнес-процессами и конструктор сущностей, унаследованный от CUBA (платформа, на которой написана СЭД ТЕЗИС). Таким образом, можно создавать свои собственные типы объектов и задавать регламент их обработки. А функции раздачи поручений и контроля в принципе инвариантны относительно предметной области, поэтому наш опыт из СЭД оказался вполне применим.
Зачем нужно было менять старую систему
Золотое правило «работает – только ничего не трогай» применимо до определенного предела, пока люди готовы терпеть неудобства старой системы и не видят других реальных альтернатив. В нашем случае было два раздражающих фактора:
- Обособленность, из-за чего кураторам приходилось работать в двух системах, а финансистам – в трех. Следствием этого была рассогласованность данных, повторный ввод и ошибки.
- Неспособность работать в географически распределенной среде, чтобы обеспечить взаимодействие между предприятиями холдинга и консолидацию данных.
И еще (это обнаружилось уже на внедрении): Во время опытной эксплуатации готовились отчеты в двух системах, старой и новой. В одном из отчетов нашли расхождение. Естественно, объявили это багом новой системы. Однако, когда все тщательно проверили вручную, пришлось признать, что это ошибка старой системы.
ОК, все программисты ошибаются, бывает. Но одно дело ошибки логические, которые можно выловить на этапе тестирования и другое дело ошибки из-за ненадежной архитектуры: то, что хорошо работает для одного пользователя не всегда удачно масштабируется в распределенной многопользовательской среде.
В старой системе бюджетирования возникали проблемы вследствие использования режима совместного редактирования таблиц – такой механизм ввода первичных данных был предусмотрен, но при этом трудно контролировать целостность данных. В ТЕЗИС все транзакции сразу идут через сервер, и подобная коллизия просто не может произойти.
Интеграция хороша для интегратора, но не всегда для заказчика
Крупную организацию невозможно автоматизировать при помощи одной единственной системы, навесив на нее все задачи – такова правда жизни. Обязательно найдутся задачи, для которых функциональный заказчик потребует внедрить какое-нибудь особенное решение, а потом извольте обеспечить сквозные бизнес-процессы! Интеграторов это, безусловно, радует, а ИТ-службу заказчика – далеко не всегда.
Но что совершенно недопустимо по современным меркам, так это наличие «островков автоматизации» – обособленных систем, которые невозможно включить в общий контур обмена информацией. НК «Альянс» столкнулся как раз с такой ситуацией: система, используемая на тот момент казначейством, была полностью обособлена – не взаимодействовала ни с бухгалтерией, ни с СЭД.
Поэтому трезво поразмыслив, заказчик решил сократить число систем и отказаться от прежнего решения, переложив его функциональные «обязанности» на ТЕЗИС. С архитектурной точки зрения, такое упрощение ландшафта есть несомненное благо. Если задачу можно решить меньшим числом систем, обязательно надо так делать.
В 1С всех пользователей не загонишь
Пока бухгалтер не создаст платежное поручение в своем 1С и не отправит эту платежку в банк, деньги никуда не уйдут, будь ваша заявка хоть трижды согласована и утверждена. Если вы принесете ее в бухгалтерию на бумаге или даже пришлете как документ по электронной почте, вам придется ждать, пока бухгалтер забьет ваши данные в свою систему. А этих заявок тьма-тьмущая.
Вам же, как всегда, нужно срочно, да? Так помогите бухгалтеру, заполните платежку сами. Не умеете работать в 1С? Понятно… Так же и бухгалтеру не хочется изучать лишние системы. Поэтому чтобы никого не напрягать, решили все процессы согласования заявок вынести в ТЕЗИС, а благодаря проверенным механизмам интеграции с 1С, реализовать взаимодействие компаний в холдинге.
«Так в 1С есть и документооборот!» – скажет внимательный читатель. И он будет прав, но заказчик получил негативный опыт с этим продуктом на другом проекте, и не хотел вновь рисковать. А история с ТЕЗИС развивалась вполне положительно – система документооборота уже была в промышленной эксплуатации.
В итоге все инициаторы платежей сами делают в ТЕЗИС заявки на оплату (в большинстве по шаблонам), на основе которых формируются платежки в 1С, а бухгалтеру достаточно их просто проверить, а не набивать с нуля.
Не все шло гладко
Допустим, технические возможности системы позволяют вам делать что угодно – хоть документооборот, хоть казначейство, хоть семечками торговать – на базаре или на бирже. Гибкость – 100%. Сущность и процессы – какие угодно. Но почему же мы видим, что компании, даже оснащенные универсальным инструментарием, очень медленно проникают в новые предметные области? Потому что в любом деле нужно наработать экспертизу, прежде чем станет все легко получаться.
Заявка на оплату– это не обычная служебная записка, у которой есть лишь номер и дата. Во всяком новом деле есть нюансы, поэтому приходилось и переделывать продукт по мере уточнения требований и накопления знаний.
Вот, например: сначала сделали по-простому – одна заявка – одна бюджетная статья. Оказалось, что это не совсем удобно, потому что одна заявка может проходить по разным статьям, например, когда в рамках одного договора вместе с каким-то товаром идут услуги по его установки/внедрению.
С учетом ежемесячного финансового планирования, на основе которого в конечном итоге и формируются заявки на проведения платежей, возможность гибко работать с этим самым платежами крайне важна. Реализованная система контроля казначейской деятельности на базе СЭД Тезис позволила сократить время по работе с финансовыми заявками за счет возможности формирования единой заявки, которая сначала включается в финансовый план, а затем сразу после подписания первичных документов отправляется на согласование к оплате, что довольно типично в 90% случаев.
Сотрудники финансовых служб в свою очередь получили возможность разбивать заявку на несколько платежей, переносить их между месяцами и осуществлять более низко-уровневое планирование при помощи платежного календаря.
Повод для гордости
В целом команда ТЕЗИС успешно справилась с проектом. На основе СЭД была построена система автоматизации работы казначейства в крупном холдинге, которая обеспечивает работу с бюджетом движения денежных средств, проверку лимитов, согласование и планирование платежей, отслеживание фактов оплаты.
Заказчика полностью устроило новое решение. Как это часто бывает, какое-то время в процессе внедрения пользователям приходится параллельно работать в двух системах, а поскольку люди консервативны, то новое порой приживается с трудом, под административным нажимом. В НК «Альянс» этого не произошло. (Опять-таки по причине того, что автоматизация казначейства по сути была расширением функциональности СЭД.)
Географический фактор часто рушит самые правильно написанные планы, а удаленное общение не всегда компенсирует живое. И здесь тоже все было успешно. Судите сами: функциональный заказчик в Москве, разработчик в Самаре, а внедрения по всей России. При этом потребовалось всего две командировки – на запуск проекта и на сдачу. Остальное время общались удаленно, однако весьма интенсивно, даже побили все рекорды в компании заказчика по длительности конференц-коллов по Skype. Конечно, сэкономили на командировках, но есть еще один момент: пользователями должны были стать высокопоставленные сотрудники финансовой службы, которые всегда очень заняты – можно было бы ловить возле кабинетов их целыми днями, зря тратя время своих аналитиков, тогда как разговор по Skype мог быть запланирован на удобное для всех время.
Не бояться новых вызовов, но не лезть на рожон
Реализуя задачу управления казначейством, мы фактически вторглись на территорию ERP со своей СЭД системой. Это стало возможным благодаря универсальной платформе CUBA, и в принципе нет архитектурных и технических препятствий, для того, чтобы разработать на этой платформе полнофункциональную ERP.
Подводя черту, можно сделать вывод:
Имея в руках СЭД, в основе которой лежит универсальная гибкая платформа, можно ввязываться в самые разнообразные проекты, далеко выходящие за рамки традиционного документооборота. Риск связан не с технической стороной, а исключительно с компетенцией в предметной области.
Конечно, СЭД не заменит ERP или CRM, чтобы довести кастомное решение до уровня продукта, придется много поработать – и это будет уже другая история. Если кто-то возьмется – welcome! Стоппером здесь может быть только недостаток соответствующих компетенций в предметной области.
Историю этого проекта и отзывы заказчика можно прочитать тут.
