Всем привет! 

С первой моей статьи прошло довольно много времени, поэтому коротко напомню о чем собственно речь. В цикле статей я делюсь своим опытом внедрения в небольших компаниях (до 100 человек) управленческого учета путем создания системы автоматизированного (т.е. с участием человека) сбора данных. На первом шаге необходимо подготовить компанию к планируемым изменениям. Итогом шага должен быть сформированный документ с описанием процессов компании. Более подробно о первом шаге можно прочитать в первой статье цикла. 

Завершив первый шаг, можно двигаться дальше и переходить ко второму шагу - выбору специализированного ПО, которое будет решать задачи сбора данных, агрегирования этих данных, формирования отчетов и создания дашбордов с показателями компаниями. 

Найти одно готовое ПО, которое всё вышеописанное может делать одинаково хорошо, достаточно трудно. Надо быть готовым, что придется внедрять в компании несколько продуктов, которые работают в одной связке.

Начинать надо с выбора ПО, которое должно собирать первичные данные, являющиеся фундаментом учета.

В данной статье я не буду называть конкретных производителей ПО. Цель статьи дать читателю инструмент, который поможет выбрать правильный софт для решения задачи. Таким инструментом будет чек-лист с вопросами, которые надо задать разработчику ПО.

Но, прежде чем я начну перечислять вопросы, хотел бы сделать пару вводных. 

В первой статье я рассказывал, как описать бизнес процесс с которым можно идти к разработчику ПО. Без формулирования данного процесса “пускаться во все тяжкие” по поиску специализированного софта не вижу смысла.  Данный документ - это перфокарта, через которую можно смотреть на софт и понимать, решит ли он вашу задачу или нет. За вас этот документ никто не сделает, т.к. только вы знаете как надо организовать работу правильно. При наличии описанного процесса общение с разработчиком переходит из разряда “возьмите наш софт он может все”, в плоскость вопросов ответов из серии: “Может ли ваш софт показать таблицу счетов таким образом, чтобы менеджеры видели только свои счета, а бухгалтерия все?” Т.е. процессом выбора ПО начинаете управлять вы, а не продавец и ваш окончательный выбор будет взвешенным и осознанным.

Второе вводное касается непосредственно вопроса управленческого учета. Хотел бы предостеречь от ошибки, попытаться убить одним выстрелом двух зайцев и вести как бухгалтерский так и управленческий учет в одной программе. 

Казалось бы почему нет, первичные данные, которые вносят пользователи используются и в управленческом и бухгалтерском учете и возникает соблазн их объединить. По своему опыту скажу, лучше этого не делать. Не зря же назвали эти два учета по разному ?. В интернете можно найти множество статей, с детальным разбором этих видов учета и их отличий. Поэтому не буду сильно здесь погружать вас в эту тему, опишу лишь основную идею: бухгалтерский учет создавался для формирования отчетности в надзорные органы, т.е. это учет был разработан под “государственный” стандарт, с общепринятыми процессами проводок, счетов и отчетов. Любого бухгалтера спроси, что такое 51 счет и он не задумываясь ответит, что это приходы и расходы по расчетным счетам в рублях.  Кроме того, бухгалтерский учет создавался чтобы  “смотреть” назад, и делать отчеты в налоговую за прошедшие периоды. Управленческий же нужен, чтобы на основании собранных данных оценивать результат работы и смотреть вперед, формируя планы и прогнозы.

На программном уровне лучшим решением будет миграция данных между ПО для управленческого и бухгалтерского учета (например, таскать из ПО для бухгалтерского учета в ПО для управленческого историю по счетам, оплатам и т.п.). 

Теперь к вопросам. Важно, чтобы вы их задали разработчику ПО и получили на них понятные вам ответы. При этом  порядок вопросов не важен. 

Есть ли возможность у ПО передавать и принимать данные от сторонних ПО?

Как я писал выше, ПО из коробки, которое закроет все ваши задачи по автоматизации бизнеса (что я под этим подразумеваю описано в моей первой статье), не существует и надо быть готовым к тому, что придется потратить время на поиск нескольких решений, которые закроют большинство ваших потребностей. Применимо к нашей теме, автоматизация предполагает автоматическое создание отчетов. Большинство CRM конечно могут делать  примитивные отчеты, но чтобы получить отчет с несколькими уровнями вложений и возможностью фильтрации данных в режиме онлайн, нужно использовать уже BI системы. Поэтому решение по сбору первичной информации (например, CRM) должно уметь передавать данные в BI систему, также как и BI должна уметь забирать данные из специализированного ПО для сбора данных.

Почему так сложно найти ПО, которое и данные удобно собирает, и отчет удобный делает? Дело в том, что разработчики, ставя перед собой целью разработать софт, выбирают инструменты наиболее подходящие для решения той задачи, которую должен решить будущий программный продукт. Например, если ПО должно работать с большим массивом данных, то упор делается на надежную и быструю базу данных, а уже после подбирается графическое решение, которое с данной БД совместимо. И наоборот, если софт должен красиво рисовать графики с возможностью их кастомизации, то сначала выбирается графическое решение, а потом уже подбирается совместимая база данных. Т.е. разработчику всегда приходится чем-то жертвовать. Поэтому найти один софт, который все делает одинаково хорошо практически невозможно. Но есть и хорошие новости, придуманы качественные стандарты интеграции софта разных производителей между собой. Интеграция позволит взять самое лучшее из каждого ПО, в одном собирать данные, а в другом их визуализировать. Поэтому один из первых вопросов, который стоит задать разработчику, это какие встроенные возможности интеграции существуют в ПО. Если в ПО отсутствует возможность принимать или передавать данные в стороннее ПО, то его можно смело ставить на последнее место в вашем списке претендентов (а лучше сразу вычеркнуть).  

Есть ли многопользовательский режим?

Если сбор данных построен правильно, то существует ненулевая вероятность, что два (или более) пользователей захотят поработать с одной и той же записью. Практически каждый производитель ПО заявляет, что у него есть многопользовательский режим, но тут начинаются нюансы: какое изменение сохраниться, если два пользователя одновременно редактируют разные поля в одной записи? А если одно и тоже поле? Конечно предпочтительно, чтобы в последнем случае работала система предупреждений о редактировании документа другим пользователем. Если такой системы нет, то будьте готовы к спорным ситуациям между сотрудниками, которые были уверены, что именно его запись должна была сохраниться.

Можно ли посмотреть, кто и что делал в системе?

Данный вопрос вытекает из вышеописанной ситуации, когда необходимо разобраться кто, когда и что делал в системе. За это в ПО отвечает раздел логирования. Логирование должно быть доступно администратору, не должно сильно нагружать систему и тратить много памяти. Также результат логирования должен быть понятен рядовому пользователю, а не зашифровано аббревиатурами, которые понятны только разработчику.

Скорость работы?

Данный вопрос напрямую задавать конечно странно, но это важный показатель, который надо учитывать при выборе. При оценке скорости необходимо обязательно брать во внимание количество одновременно работающих пользователей в системе и что эти пользователи делают (просматривают, редактируют или выгружают данные). ПО может отлично работать с пятью пользователями и жутко тормозить уже с десятью. На какое-то время решение с увеличением вычислительных мощностей может решить эту проблему, но если код написан не оптимально, то потолок отклика будет достигнут достаточно быстро. А софт вы покупаете не на год и два, поэтому медленный отклик системы со временем может перерасти в большую проблему. Сложность вопроса заключается ещё и в том, что разработчик вряд ли тестировал свой софт на данных, которые копились несколько лет. Просто потому что у разработчика, скорее всего, нет такого объема данных. Поэтому на слово верить продавцам софта в этом вопросе я бы не стал. Лучше посмотреть портфолио компании и получить рекомендации от тех, кто данным софтом уже пользовался. Ну и конечно, в тестовый период постараться “загрузить” систему множественными переходами по закладкам, редактированием записей несколькими пользователями с выгрузкой тестовых данных.

Надо ли ставить дистрибутив у пользователя или решение облачное?

В наш век интернета, ещё остались компании, которые требуют устанавливать дистрибутив на компьютер пользователя. На мой взгляд, при выборе решения надо ориентироваться на версии, которые работают в браузерах и не требуют дополнительной привязки пользователя к рабочему месту. Это действительно удобно. Другой вопрос - это где будет расположен центральный сервер на котором будет работать решение и хранятся данные: на мощностях поставщика ПО или на вашем сервере. Если приоритетом компании является высокая конфиденциальность данных, то ответ очевиден, необходимо ставить сервер на собственных мощностях. А если говорить о небольших компаниях, то я бы рекомендовал пойти по пути приобретения SAAS лицензии, а со временем, когда в штате появиться свой сисадмин, переходить на серверную версию. Поэтому лучше сразу узнать предусмотрен ли безударный переход с лицензии SAAS на серверную.  

Можно ли данные выгружать, например, в Эксель?

Стоит признать, что как бы классно не были настроены отчеты, периодически возникает необходимость выгрузить данные, чтобы с ними поработать. Данная задача возникает, когда компания растет и у неё появляются новые точки контроля, которые необходимо настроить. Лучшего инструмента, чем Эксель, который позволит быстро проверить математическую модель на работоспособность перед тем как её внедрит, я лично не знаю. Кроме того, все-таки есть вероятность, что купленный софт вам не подойдет и надо выгрузить данные, чтобы либо вернуться в Эксель, либо загрузить их в другой софт. Поэтому конечно, софт должен уметь выгружать данные с помощью встроенного функционала и желательно в популярном формате.

Можно ли загружать данные, например, из Эксель?

Если вы вели вашу базу в Эксель, то на этот вопрос у разработчика должен быть однозначный ответ: “Да, может!”. Получив такой ответ, необходимо провести тесты по загрузке вашей базы в ПО. Причем не руками разработчиков, а с помощью встроенных инструментов ПО. Наличие данного функционала существенно облегчит вам жизнь на следующем шаге автоматизации, когда надо будет заполнять базу данных вашими данными (но об этом в следующей статье). 

Есть система отчетов?

Хорошо чтобы она была. На первых этапах автоматизации, вам может хватить имеющихся. Поэтому лучше, чтобы ПО умело строить графики и диаграммы, хоть и примитивные. Это позволит сэкономить ресурсы на интеграцию с BI системами, которое можно будет сделать позже, когда основные процессы будут отлажены.

Возможности самостоятельной конфигурации таблиц, связей?

В большинстве готовых решений архитектура таблиц незыблема и чтобы её изменить требуется доработка, которая по стоимости может в разы превышать стоимость самого софта. Поэтому если разработчик заявляет, что в системе есть возможность конфигурирования, то надо детально выяснить, что он под этим подразумевает: это может означать как возможность создания таблиц с нуля с настройкой связей между таблицами, так и возможность  изменения только названия столбцов и их добавления в рамках одной таблицы. И если в первом случае, вы покупаете конструктор с помощью которого можно строить свою архитектуру данных, то во втором вы покупаете готовую архитектуру (как её замыслил разработчик) в которой возможности конфигурирования сильно ограничены. 

Приобретая конструктор надо понимать, что на этапе внедрения разрабатывать самостоятельно свою архитектуру - это более затратная история, чем внедрение готового решения. Однако, в перспективе такой подход позволит создать уникальную архитектуру именно для вашей компании, а также сэкономить средства на оплату доработок разработчикам готовых решений, т.к. вы самостоятельно сможете развивать или менять архитектуру без привлечения дорогостоящих программистов.

Как работает система доступа и можно ли самому её конфигурировать?

Первичные данные компании - это конфиденциальные данные и лишний раз показывать их сторонним людям (например, разработчику ПО) не хочется. Кроме того, сотрудники компании, должны иметь доступ только к той информации с которой они работают. Для этого в ПО должен быть встроен инструмент, с помощью которого администратор  сможет, без привлечения разработчиков, изменять права пользователей. Идеально, если данный инструмент не только позволяет настроить пользователям видимость полей, таблиц разделов и т.п., но и создать более сложные правила доступа и редактирования. Например, чтобы менеджер по продажам мог редактировать только свои записи по счетам клиентам.

Как осуществляется поддержка?

Сейчас при развитии ИИ, многие производители ПО пытаются переложить на его плечи первичную оценку проблемы. Зачастую это работает мягко говоря не очень хорошо, даже у больших и солидных компаний, которые вкладывают немалые деньги в разработку. На первых этапах работы с ПО будет множество вопросов и пробиваться каждый раз через анкету стандартных вопросов ИИ крайне затратно, поэтому лучше если у разработчика ПО есть "живая" поддержка (желательно круглосуточная). Это будет большим плюсом при прочих равных условиях. Другой вопрос, что качество саппорта бывает не многим лучше ИИ. Проверить это можно сделав пару тестовых запросов в саппорт на этапе тестирования ПО. С учетом того, что вы потенциальный клиент и в вас заинтересованы, скорость ответов и решений должна быть близка к скорости света. Если вас ставят на длительную паузу, то надо искать другой выход из ситуации, например, получить своего аккаунт менеджера, к которому можно обратиться, если поддержка не решает ваш вопрос. Без саппорта, который оперативно закрывает ваши вопросы, внедрение нового решения будет проходить крайне медленно.

Что будет если сервер сломается?

Чтобы оценивать результат и строить прогнозы необходимы первичные данные. Это основа учета и должна быть полная уверенность, что эти данные будут в сохранности в любых обстоятельствах. Регулярно вручную выкачивать данные из ПО - это дорого и неэффективно. Необходимо, чтобы софт имел встроенные инструменты автоматического бэкапа, а также сразу позаботится о дополнительной памяти, чтобы хранить бэкап. Узнайте у разработчика, какие есть инструменты и правила для создания автоматического бэкапа, делается ли полный бэкап или сохраняются только изменения с последнего бэкапа, возможно ли настроить расписание и как восстановить данные самостоятельно.

Безусловно, это не полный список вопросов, которые можно задать разработчику. Данный чек-лист охватывает лишь основные моменты, которые надо оговорить, чтобы в середине внедрения не разочароваться в выбранном решении. Повторюсь, в основе вашего с разработчиком общения должно быть ваше представление о бизнес процессах компании. Только сформулированное видение как вы хотите организовать в компании сбор данных позволит выбрать правильное решение. И после выбора ПО обязательно надо потратить время на тестирования решения, для этого практически у всех решений есть бесплатный тестовый период.

Теперь, хочу пару слов сказать не о “коробочных” решениях. В качестве альтернативы можно рассмотреть вариант найма разработчиков, которые с нуля разработают решение, удовлетворив все ваши  хотелки. Но это уже будет крайний шаг, когда готовые решения на рынке вам не подойдут. При таком развитии событий, вам самим уже надо будет становиться Product owner и погружаться во все нюансы этой работы. Если вы готовы, то дерзайте. 

В заключении скажу, что я в свое время остановился на конструкторе, в котором можно с нуля создавать архитектуру таблиц и связей. Процесс внедрения небыстрый и зачастую получалось так, что к моменту завершения внедрения часть задач, которые ставились на старте, отваливались и при этом появлялись новые. Это естественный процесс связанный с ростом компании, которая развивается и двигается вперед. Поэтому для  меня первоочередным было наличие возможности расширять систему, без привлечения сторонних разработчиков. Получив в свои руки гибкий инструмент, которым является конструктор, можно без больших вложений скорректировать результат и быть готовым к решению новых задач. 

Выбор специализированного ПО очень важный шаг и к нему надо подойти со всей ответственностью не жалея ресурсов. Ведь от успешности итогов второго шага на пути организации учета, зависит качество данных, на основе которых будут в дальнейшем приниматься управленческие решения.

Всем успешных внедрений!