Заметки эксперта В поисках идеальной ERP

Александр Попов

Александр Попов, директор AVA Systems, www.avasystems.ru

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

Возраст самого термина – ERP, Enterprise Resource Planning – уже весьма почтенен. Однако его практическое применение, т. е. сами ERP-системы, на мой взгляд, и по сей день пребывают в состоянии едва ли не юношеском. До зрелости еще очень далеко, причем это относится не только к России. Да, на Западе много компаний, имеющих огромный опыт использования ERP (чего стоит одна только Toyota!), но все они, как правило, пользуются собственными разработками. Разработками, которые создавались десятилетиями и в которые вложены огромные деньги. Некоторые флагманы мировой промышленности даже значительно влияют на саму культуру планирования ресурсов как таковую, порой меняя привычные принципы планирования.

Первые достойные внимания попытки разработать и внедрить в России в промышленную эксплуатацию что-то подобное ERP-системе были предприняты еще в середине 90-х годов. В одном из таких проектов участвовал и автор этих строк. Это была компания из 1500 сотрудников, имевшая девять региональных филиалов (с содроганием вспоминаю, чего нам стоило все это объединить в единое информационное пространство, учитывая тогдашнее качество каналов связи). Конечно, назвать те попытки разработкой ERP-системы сегодня даже язык не поворачивается. Это скорее были прототипы, модели нынешних решений. Все мы тогда учились, причем в основном на своих собственных ошибках. О чужих-то мы не знали.

Не царское это дело?

Много лет назад, еще в 90-е, разработчики рассматривали свои EPR-системы как вершину айсберга корпоративной автоматизации. Мол, не царское это дело – автоматизировать транзакционную часть. Пусть всякие низменные накладные, проводки и прочие мелочи проходят в других системах, а ERP должна только планировать. Попытки реализовать такой подход на практике приводили к тому, что заказчик получал некий «черный ящик». Количество проблем увеличивалось вдвое, расходы на поддержку зоопарка систем – в десятки раз. С нулевым результатом.

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

Любое изменение в транзакционной части (и, не приведи Господи, еще и задним числом, что мы в России очень любим делать) должно было сопровождаться соответствующими изменениями в ERP. Вот для обеспечения реакции на такие изменения и содержали «программистов-кочегаров», которые в случае чего засучивали рукава и в поте лица гоняли данные из системы в систему. И оказывались такие «кочегары» людьми едва ли не самыми важными в бизнесе, без которых ни одно производственное совещание не обходилось.

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

В конечном счете здравый смысл возобладал и пришло понимание, что ERP-система – единый организм. Отдача от ее эксплуатации может быть только в одном случае – когда все процессы замкнуты в рамках единой ИС масштаба предприятия, основанной на одном продукте. Лишь при этом условии можно обеспечить связь всех бизнес-процессов и целостность информации. Кроме того, устойчивость такой системы значительно выше. Ну скажите, какой смысл в цифре, агрегирующей, например, объемы продаж, если нельзя посмотреть, как эта цифра получилась. Чувство недоверия к показателям не покинет пользователя никогда, если система не обеспечивает возможности оперативной проверки любой цифры и не позволяет добраться из отчета до первичных данных. Получается, что отчетность смотрим в одной системе, первичные данные – в другой, и связь этих данных друг с другом поддерживается только до тех пор, пока не уйдет в отпуск «ответственное за интеграцию» лицо. А работать-то нужно всем.

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

Бизнес осознал, что информация должна быть доступна и актуальна практически в онлайновом режиме, а все корпоративные данные должны иметь единый формат, быть формализованы в единых терминах и содержаться в едином хранилище.

Ни в коем случае не нужно забывать о главном назначении ERP-системы: дать руководству компании возможность принимать своевременные управленческие решения и планировать бизнес. Как следствие современный продукт просто обязан обеспечивать «свежесть» управленческой информации. Получая данные о состоянии бизнеса с интервалом в два месяца, руководитель мало что сможет сделать. В особенности если речь идет о нестабильных экономических условиях, когда решения нужно принимать мгновенно.

Чего мы хотим от идеальной ERP?

Кому вы больше доверяете в вопросах учета – компьютеру или человеку? Ответ очевиден. Именно поэтому отчетность о состоянии бизнеса должна быть автоматизирована и не зависеть от настроения сотрудников или их присутствия на рабочем месте. В системе не должно быть промежуточных звеньев между вводом первичных данных и генерацией результирующей отчетности.

Прибыли и убытки компании

Если говорить об идеальном решении, то система должна обладать встроенными инструментами для бизнес-анализа (BI, Business Intelligence). Современная отчетность – это не только привычные «прибыли и убытки», «движение денежных средств» и «баланс», но и другие инструменты для анализа и оптимизации бизнеса. Современная BI-система должна давать ответ на целый ряд важнейших вопросов, стоящих перед руководством компании. Вот лишь некоторые из них.

• Какова выручка компании, что представляет собой структура доходов по направлениям деятельности, по подразделениям фирмы, по клиентам, по товарным направлениям, по сделкам, по динамике и т. д.? Предположим, компания занимается поставками, монтажом и сервисом. По каждому из трех направлений планируется выручка на год вперед. А затем наблюдаем за фактическими показателями. Если сервис отстает, значит, необходимо принимать меры. Клиенты, приносящие наименьшую выручку, – это поле для деятельности по ее увеличению. Клиенты, приносящие максимум выручки, – это те клиенты, которых надо любить и чью лояльность всячески поддерживать. Если можно планировать выручку не только по всей компании, но и по ее подразделениям – значит, и анализ фактических показателей нужен в этом разрезе.

• Каковы затраты компании и какова их структура по статьям и подразделениям? Определяя бюджеты по статьям затрат и подразделениям, можно удержать затраты в заданных границах. Если, конечно, система позволяет это гибко контролировать, т. е. менять маршрут прохождения затрат в компании при превышении бюджета. Не забывайте, что затраты влияют на прибыль не меньше, чем выручка.

• BI-система должна позволять рассматривать показатели деятельности в различных разрезах с тем, чтобы проводить мероприятия по их оптимизации. Необходима возможность получить любой показатель в таких разрезах, как «клиент» («поставщик»), «товар», «сотрудник» («менеджер»), «отдел» (и «группа отделов»), «своя» организация, «проект». Это минимум. Плюс средства отслеживания динамики изменения показателей.

• Каков платежный баланс бизнеса? «Где деньги, Люся?» – иными словами. Руководство должно четко представлять финансовые потоки предприятия и понимать, насколько в компанию входит денег больше, чем из нее выходит. (Про «наоборот» говорить не хочется.) На такие вопросы однозначный ответ дает отчет о движении денежных средств (Cash&Flow). Но простой картины финансовых потоков недостаточно. Всегда хочется понять, какие подразделения принесли эти деньги, какие клиенты, по каким сделкам и т. д. И при этом необходимо иметь возможность все это делать непосредственно в отчете, только тогда видна ясная причинно-следственная связь. В то же время желание видеть платежный баланс в одном отчете автоматически накладывает на функциональность ERP-системы целый ряд требований по контролю движения денежных средств. Например, система должна позволять проводить огромное количество операций – от прихода денег по счету до банковских кредитов и налоговых компенсаций. В противном случае просто невозможно обеспечить в системе все финансовые операции и получить целостную картину. Так что система автоматизации должна позволять контролировать остатки в банке и кассе, т. е. плавно возникают требования по обеспечению финансовых транзакций.

ERP-система – это не только инструмент для автоматизации бизнеса, но средство для принятия решений.

• Каков баланс бизнеса? Руководству нужно однозначно знать дебиторскую и кредиторскую задолженность компании, причем отдельно по поставщикам и клиентам. Понимать, какие клиенты (поставщики) и в каких суммах ее сформировали, по каким сделкам, какие менеджеры в этом участвовали и т. д.

Для принятия правильных решений не помешало бы иметь не только финансовые показатели, но и количественные. Думается, что всем руководителям интересно знать, растет ли количество клиентов и новых проектов и как. Растет ли посещаемость сайта и как это стыкуется с объемом продаж. Как меняется количество сотрудников. Ну и масса других показателей.

Cash&Flow бизнеса

Обладая автоматизированными отчетами, легко держать бизнес в руках, имея возможность эффективно управлять им. Но при внешней простоте требований сегодня таких предприятий в России немного. Как правило, подобная отчетность формируется в лучшем случае полуручным методом, а часто ее нет и вовсе. Увы, но на практике бизнесом чаще управляют по принципу «буду закручивать, пока не лопнет».

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

Сложности реального мира

Любая сделка – это довольно серьезный бизнес-процесс. Вот простой пример: «заказ клиента – коммерческое предложение – договор – счет клиенту – предоплата – заказ поставщику – счет поставщика – заявка на его оплату – платеж поставщику – накладная поставщика – приход товара – оформление доставки клиенту – отгрузка со склада – накладная, счет-фактура – закрытие сделки». И все эти процессы должны быть объединены в рамках какого-то проекта. (Заметьте, это еще без производства, а с ним все значительно усложняется.)

Идеальная ERP-система должна обеспечить автоматическое формирование бумажного отражения всех документов (если они требуются в процессе) без применения подручных средств. С последующим хранением копий этих документов (в отсканированном виде) в базе данных. Каждый документ сделки тоже может проходить определенный путь. Допустим, договор нужно оформить, подписать, получить подпись клиента. И всем должно быть ясно, на какой стадии договор находится в текущий момент, на какой стадии находится вся сделка в целом. Пользователь, заходя в систему, должен видеть, что в данный момент процесс находится, например, в стадии заказа поставщику. Посмотреть, как был оплачен счет, кто подписал договор с нашей стороны, когда и т. д. У какого поставщика заказан товар и когда ожидается его поступление. Масса вопросов по каждой сделке, отсутствие ответов на которые зачастую вызывает у руководства буквально истерику. Потому что каждый работает в каком-то своем «микрокосме», в своей частной системе (CRM, SCM, а то и просто Excel).

Современная ERP-система просто обязана обеспечивать прохождение всех бизнес-процессов, от получения заказа от клиента и до доставки груза. И не только обеспечивать, но делать эти процессы неразрывными и целостными. Это значит, что в любой момент должна быть возможность пройти по всему процессу от начала до конца. Да, это огромный функционал – но он не избыточен. Ведь именно так и обстоят дела в реальной жизни практически в каждой компании, где трудится хотя бы десяток человек.

Выбираем ERP-систему

Внедрение ERP-системы – не аморфный процесс, а совершенно конкретный и формализованный, с четко расписанным сценарием принятия решения.

Для успеха необходимо несколько ключевых слагаемых. Вот они:

• понимание заказчиком собственных потребностей;

• качественно разработанное техническое задание (если речь не идет о внедрении «коробочного» решения);

• воля руководства компании-заказчика;

• качественный, работающий продукт;

• профессиональный консультант со стороны исполнителя, который не даст проекту пойти по неверной дороге;

• отсутствие хаоса в бизнес-процессах предприятия.

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

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

2. Определитесь с потребностями. Недавно поинтересовался у одного из потенциальных клиентов задачами, которые он хотел бы решить. Ответ был гениален: «Хочу наладить управленческий учет». Определяйтесь конкретнее, расписывайте детально свои требования. (Пример таких требований можно увидеть во врезке «Примерный список требований к ERP-системе».)

3. Пробуйте! Постарайтесь получить возможность поработать с системой, которой заинтересовались, «вживую». Это не всегда просто, отдельные разработчики не предоставляют не только демоверсий, но даже и снимков экрана. Но это обязательное требование, причем крайне желательно не просто «потыкать кнопки», а пройти как можно больше цепочек конкретных бизнес-процессов и проверить, где есть проблемы, а что работает «из коробки». Если вы договорились о проведении презентации – вооружитесь списком функциональных требований и приготовьтесь к тому, что придется выжимать подробности буквально по капле. О том, как этого избежать, см. статью «Как не дать себя обмануть на презентации ERP» (http://avasystems.ru/press/ne_obmanesh).

4. Изучите инструкции. Попросите разработчика представить инструкции для администратора системы и для пользователей. Здесь могут возникнуть проблемы, ведь разработчики зарабатывают серьезные деньги на обучении работе со своей системой. Но добыть эти инструкции необходимо – равно как и поработать по ним в тестовой системе. Постарайтесь понять, насколько они применимы в реальной жизни и насколько понятны. Если вам с серьезным видом рассказывают, что «в каждом случае мы разрабатываем отдельные инструкции», стоит задуматься, поскольку если нет инструкций – значит, готовьте деньги. Отсутствие ясных инструкций для пользователей – первый признак будущих проблем.

5. Функциональность и завершенность. Чем лучше продукт готов к эксплуатации «здесь и сейчас», тем меньше он будет стоить при внедрении и эксплуатации. В реальной работе нужен не тот продукт, который все может в потенциале (о чем с гордостью рассказывает красочный рекламный буклет), а тот, который уже сейчас многое может. Поэтому задавайте предельно конкретные вопросы. Лучше пользоваться готовым (читай, менее дорогим) инструментом, может быть, в чем-то себя ограничив, нежели что-то «дорабатывать напильником» (как показывает практика, это в десять раз дольше и дороже).

6. Не боги горшки обжигают. Любое внедрение ERP – это не только и не столько консалтинг, сколько уйма рутинной работы по настройке системы. Работу эту делают обычные люди – не боги, не небожители, не гуру. Сакральным знанием они могут и не владеть (а документации, кстати, может не быть даже у них). И вот в эту работу лучше погрузиться самостоятельно. Не бойтесь самостоятельной настройки. Если есть хорошего качества инструкции, вы справитесь.

Best Practice, или Чудес не бывает

В презентациях разнообразных консультантов, продающих ERP-системы, часто встречается термин Best Practice. В ERP-мире это, как правило, означает, что нам рассказывают: мол, на Западе уже давно все придумали, и изобретать велосипед вовсе не требуется, просто возьмите оттуда лучшее.

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

Бывает и так, что 70% сделок проходят по весьма разветвленным схемам, связывающим интересы многих контрагентов. Возникают существенные – до 50%!– расходы на проведение сделки, а это чистейший убыток, значит, он должен закладываться в себестоимость сделки. Расскажите об этом западным компаниям – не поверят.

Простой пример. Представьте, что у вас есть клиент. У него – пять юридических лиц. Стандартная ситуация. Нужно вам знать, сколько вам задолжало каждое из этих пяти юридических лиц? Обычно нет, разве что при формировании бухгалтерского акта сверки. В большинстве случаев необходимы показатели по клиенту в целом. Это касается и дебиторской и кредиторской задолженности, и объемов продаж и дохода. Сплошные аффилированные структуры – чисто российская особенность. А для принятия решений нужно агрегировать все показатели.

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

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

1. Организация деятельности нескольких юридических лиц в рамках одной системы: невозможно.

2. Управление кадрами компании: невозможно.

3. Управление договорной деятельностью компании: невозможно.

4. Управление производством: невозможно.

5. Организация работы с клиентами: на уровне «1C:Предприятия» 7.x.

6. Управление ценообразованием: практически отсутствует. (Причем некоторые моменты просто препятствуют нормальной работе.)

7. Сквозной учет товара: разобраться не удалось. (Все закрыто и пользователю недоступно, остается только верить презентации.)

8. Формирование первичных документов: практически невозможно.

9. Управление логистикой: невозможно.

Более подробно эта история изложена на сайте http://www.avasystems.ru/press/prezent_erp.

Как можно пользоваться таким продуктом? Где эти пресловутые «наилучшие решения», Best Practice? Я не верю, что такая система может работать и на Западе, а в России приобретение подобного продукта однозначно приведет к потере времени и денег. И вот тут стоит отметить, что внедрять ERP-систему желательно с первого раза. Второй попытки внедрить что-то подобное компания может и не перенести, если сотрудники потеряют веру в непогрешимость и эффективность топ-менеджеров, восприняв очередной проект внедрения очередной ERP как очередную забаву руководства.

Примерный список требований к ERP-системе

ERP-система, как и любой другой продукт, имеет свои потребительские характеристики – и эти характеристики надо четко представлять. Не забывайте, что требования необходимо закладывать с учетом роста компании: то, что кажется избыточным сегодня, может оказаться жизненно важным впоследствии. Приведенный пример – безусловно, не истина в последней инстанции, но он дает представление об основных вопросах, которые нужно рассмотреть при выборе ERP-системы.

1. Управление бизнес-процессами предприятия в рамках нескольких родственных компаний.

1.1. Привязка всех документов и процессов к «своим» компаниям.

1.2. Нумерация счетов-фактур, приказов и других документов отдельно по каждой «нашей» компании.

1.3. Упрощенная система налогообложения.

1.4. Отчетность в разрезе компании.

2. Работа с клиентами.

2.1. Организация схемы «клиент – несколько юридических лиц». Контроль взаиморасчетов в разрезе клиента в целом.

2.2. ABC– и XYZ-категоризация клиентов.

2.3. Настройка скидок в зависимости от категории клиента.

2.4. Просмотр всех счетов, отгрузок, платежей, накладных и других документов по клиенту непосредственно на его карточке.

2.5. Закрепление менеджера за клиентом. Регулирование доступа менеджеров к своим клиентам, счетам и другим документам.

2.6. Формирование прайс-листа.

2.7. Учет ребейтов.

2.8. Установка и контроль лимита дебиторской задолженности для клиента.

2.9. Подарки клиентам.

2.10. Организация распродаж, акций.

2.11. Отгрузка товара на реализацию.

2.12. Настройка управленческих выборок по клиентам.

3. Управление поставками.

3.1. Фиксирование плановых сроков поставки по каждому поставщику и каждой группе товаров.

3.2. Организация цепочек поставок и их сквозной контроль.

3.3. Учет затрат на поставку и включение их в себестоимость.

3.4. Поставки «под заказ».

3.5. Учет ГТД.

3.6. Планирование платежей поставщикам.

3.7. Учет кредитов от поставщика.

3.8. Планирование потребностей в закупках.

3.9. Учет входящих документов.

3.10. Выбор лучшего поставщика.

3.11. Резервирование товаров в поставках.

3.12. Оптимизация сроков поставки.

4. Договорная деятельность.

4.1. Формирование и ведение базы договоров.

4.2. Процедура согласований и утверждений договоров.

4.3. Формирование текстов договоров на базе шаблонов.

4.4. Хранение отсканированного договора и других файлов в базе данных.

4.5. Контроль сроков окончания договоров.

4.6. Типизация договоров.

4.7. Маршруты согласований договоров.

4.8. Уровни финансовых полномочий сотрудников на подписание договоров.

5. Классификатор товаров.

5.1. Возможность организации древовидной структуры. Перенос позиций из ветки в ветку.

5.2. Просмотр текущей скользящей себестоимости товара и истории ее изменения.

5.3. Детализация логистических срезов.

5.4. Ограничение доступа пользователей на просмотр себестоимости и другой информации по товару.

5.5. Настройка аналогов, аксессуаров, совместимостей и других взаимосвязей товарных позиций.

5.6. Хранение в БД изображения товара, инструкций и др.

5.7. Просмотр истории движения товара по складу и истории остатка.

5.8. Поиск документов по товару.

6. Редактор отчетов.

6.1. Возможность настройки и коррекции шаблонов документов.

6.2. Выгрузка любого документа в такие форматы, как PDF, .xls, .doc, Open Office и др.

7. Ценообразование.

7.1. Автоматический расчет средневзвешенной себестоимости при приходе товара на склад.

7.2. Ожидаемая себестоимость.

7.3. Ручная коррекция себестоимости.

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

7.5. Настройка полномочий по минимально возможным ценам (или максимальным скидкам) для разных пользователей.

7.6. Настройка рекомендуемых скидок по клиентам, категориям клиентов, товарам, группам товаров, срокам, скидкам от количества и другим параметрам.

8. Сквозной учет товара.

8.1. Учет партий, серий, серийных номеров.

8.2. История партии, серийного номера.

9. Первичные документы.

9.1. Правильное отражение ГТД в счетах-фактурах при разных партиях товара.

9.2. Формирование таких документов, как счет, счет-фактура, акт выполненных работ, торг-12, доверенность, акт сверки, ТТН, договор, приказы по кадрам и др.

9.3. Учет возврата первичных документов.

10. Склад.

10.1. Учет серийных номеров изделий, история серийного номера.

10.2. Внесение в базу серийных номеров через сканер штрихкода (желательно).

10.3. Полноценное резервирование товара на складе.

10.4. Возможность частичной отгрузки товара.

10.5. Подбор товара на складе.

10.6. Распоряжения на отгрузку и на прием товара.

10.7. Учет товара на полках.

10.8. Перемещение товара между складами.

11. Система управления доступом пользователей.

11.1. Настройка функциональных ролей пользователей.

11.2. Привязка ролей к штатному расписанию.

11.3. Ограничение доступа пользователей к процессам и объектам системы.

11.4. Возможность ограничения доступа пользователей к документам в ходе процесса.

11.5. Ограничение кладовщиков доступом только к «своему» складу.

11.6. Ограничение кассиров доступом только к «своей» кассе.

12. Управление кадрами.

12.1. Настройка структуры подразделений компании.

12.2. Настройка штатного расписания компании.

12.3. Прием, увольнение сотрудников.

12.4. Формирование и печать приказов и трудовых договоров.

12.5. Расчет зарплаты.

12.6. Премии/штрафы.

13. Управление затратами.

13.1. Структура статей затрат.

13.2. Маршруты согласований заявок на затраты.

13.3. Уровни финансовых полномочий сотрудников на подписание заявок.

13.4. Начисление затрат.

13.5. Учет основных средств и закрепление их за сотрудниками.

14. Финансы.

14.1. Стандартные отчеты о прибылях и убытках, о движении денежных средств, баланс, дебиторы, кредиторы.

14.2. Отдельно показатели по задолженности поставщиков перед нами, нас перед ними и итоговой. То же самое с клиентами.

14.3. Анализ значений показателей отчетности в разрезе сделок, клиентов, менеджеров, товаров, товарных групп, «наших» фирм.

14.4. История показателей за прошедшие периоды, например история выручки за год по месяцам.

14.5. Конвертация валюты.

14.6. Многовалютность учета и финансовой отчетности.

14.7. Банковские кредиты и овердрафты.

14.8. Оформление займов у «своих» фирм.

14.9. Неопознанные платежи.

14.10. Налоговые компенсации.

14.11. Внереализационные доходы.

14.12. Открытие и закрытие «своих» компаний и расчетных счетов.

15. Производство.

15.1. Формирование структуры изделия.

15.2. Плановая и фактическая себестоимость изделий.

15.3. Формирование сводной потребности в производимых изделиях.

15.4. Формирование и диспетчеризация сменных заданий.

15.5. Маршрут изделия.

15.6. Определение и формирование потребностей в материалах.

15.7. Производство «под заказ».

15.8. Серийное производство.

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

Девальвация термина

Разработчики давно поняли, что клиентам нужны именно ERP-системы. И поступают очень просто: называют ERP-системами свои продукты. Хотя в действительности больше половины продуктов на рынке не способны не только планировать, но даже учитывать. Сегодня любой программный продукт, умеющий печатать счета-фактуры, называют ERP-системой. Просто потому, что «клиенты хотят ERP».

В погоне за клиентом разработчики готовы называть ERP-системой любой продукт.

Как результат – термин девальвировался, и теперь уже непонятно, что есть ERP, а что не ERP. Поэтому самое надежное при выборе решения – отбросить терминологию и оперировать потребительскими характеристиками продукта: «Система должна уметь это, это и вот это. Покажите, пожалуйста. Желательно на конкретных примерах».

В противном случае могут быть сюрпризы. Однажды мне довелось присутствовать на презентации некой ERP-системы, частью которой был модуль MRP (Material Requirement Planning, планирование потребности в материалах). Это, пожалуй, самая сложная часть в планировании, и наличие такого модуля – серьезное преимущество. Но … На практике все свелось к тому, что система автоматически формировала заказ, если остаток того или иного ресурса оказывается ниже «страхового запаса». Ни сроки поставок, ни тренды продаж, ни сезонность, ни текущие поставки не учитывались. И вот это доблестные продавцы системы (западные, замечу) назвали MRP. Мало того, страховой запас нужно было указывать для каждой товарной позиции отдельно. Легко представить, как это будет работать при наличии тысяч эдак тридцати учетных позиций.

Современное планирование запасов просто обязано учитывать плановые сроки поставок по поставщикам и желательно по этапам поставки, чтобы при планировании учитывать, что если груз только заказан, значит, он будет через N дней, а если есть товарная накладная – значит, через X дней. Инициировать пополнение склада материалов нужно не в момент, когда запас уже вошел в «красную зону», опустившись ниже границы страховой части, а так, чтобы он оставался стабильным. Страховые запасы и плановые сроки поставок желательно планировать по группам однотипных товаров. Если поставщик доставляет любые ноутбуки за 60 дней – зачем указывать этот срок для каждой модели отдельно, достаточно задать его для товарной группы. Иными словами, система планирования должна быть применима практически, в противном случае потеря времени и сил гарантирована. Не говоря уже про деньги.

Haute Couture, или Ближе к народу?

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

Нередко со стороны консультантов в сторону заказчика звучат фразы: «Вы скажите, как вам надо, и мы сделаем». Да консультантов для того и приглашают, чтобы они подсказали, как делать нельзя, и что-то подправили в бизнесе. Но если консультант сам только что из института, откуда ему знать, как все сделать правильно?

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