Тиражируемость, ау, где ты?!
На так давно меня пригласили на дискуссию о будущем ERP-систем: какими они станут в будущем, какие технологии должны применяться и т.д. Как ни странно, беседа шла, в основном, о технологиях низкого уровня, о технологиях вычислений, представления данных.
На так давно меня пригласили на дискуссию о будущем ERP-систем: какими они станут в будущем, какие технологии должны применяться и т.д. Как ни странно, беседа шла, в основном, о технологиях низкого уровня, о технологиях вычислений, представления данных.
И больше всего меня поразило, что участники обсуждали, как представлять данные, а не что представлять.
Почему-то производителей не беспокоит, что большая часть ERP-решений сегодня являются не тиражируемыми, а скорее эксклюзивными. Каждый клиент платит деньги за реализацию тех же самых функций, за которые платил предыдущий. И это при том, что в большинстве своем такие функции не являются чем-то изысканным. Поэтому, на мой взгляд, сначала необходимо решить вопрос именно тиражируемости, т.е. сделать так, чтобы бизнес-приложения работали сразу, а не через год после инсталляции (да и то не факт), а затем уже думать о том, как совершенствовать технологические платформы и средства представления данных.
«Счастье в коробке»
Все понимают, что тиражируемое решение — это хорошо со всех точек зрения. Это понимает и бизнес, и разработчики ERP-систем. Производители, конечно же, сразу взяли этот термин на вооружение, и во всех пресс-релизах «пиарят» его направо и налево. Это не важно, что тиражируемостью в большинстве случаев и не пахнет. Главное, чтобы клиент прочитал пресс-релиз об очередном «успешном внедрении».
Почему ни у кого не возникает мысли переписывать «под себя» MSWord или MSExcel, OpenOffice, Adobe Reader и т.д.? Все просто: потому что эти продукты работают сразу, то есть «здесь и сейчас» (plug&play). Да, есть нюансы, кто-то чем-то недоволен, но ведь в целом все работает! И никому не приходит в голову все это переписывать. Неужели кто-то думает, что если производители ERP-систем дадут бизнесу (по крайней среднему и малому) какие-то решения, которые тоже работают по принципу plug&play, то бизнес захочет их кромсать и переписывать? Конечно же, нет! Переписывание денег стоит, и не малых, и бизнес просто вынужден этим заниматься, потому как получает откровенно сырые решения. И даже не решения, а скорее некие платформы, на базе которых за свои же деньги уже пытается сделать решение. И так каждый клиент.
Понятно, что сравнивать ERP-систему с MSWord не совсем корректно. Однако я намеренно привел именно это сравнение. В любой ERP-системе 80% функционала абсолютно одинаково для всех клиентов. Потому что все компании работают примерно по одним и тем же законам, документооборот (в особенности по унифицированным формам) тоже не сильно отличается. Каждая компания — это не отдельно взятая микроэкономика со своими законами. Если бы это было так, то не существовало бы международных стандартов отчетности, все отчитывались бы по своим собственным принципам. Финансовые и логистические потоки во всех компаниях очень похожи. Так почему не дать бизнесу некое решение, где уже настроена и работает система управления затратами, логистикой, финансами? Но только так, чтобы это решение работало, чтобы были настроены бизнес-цепочки. Я уверен, что большая часть среднего и малого бизнеса с удовольствием возьмет готовый инструмент, вместо того чтобы изобретать свой собственный, ошибаясь на каждом шагу. Другой разговор, что в рамках цепочки нужно расставить сотрудников в рамках конкретной организации. Но одно дело — определить функциональное разделение доступа сотрудников в рамках существующей цепочки и совсем другое — изобретать эту цепочку.
Кому велосипед?
На практике более половины проектов по внедрению ERP-систем превращаются в изобретение велосипеда, когда на каждом проекте разработчики делают то же самое, что и на предыдущем. И это обстоятельство не мешает производителям витать в эмпиреях, устраивать семинары, на которых рассказывать потенциальным «жертвам» о том, как «корабли бороздят просторы вселенной», а затем, когда «клиент клюнул», за его же деньги реализовывать в своих продуктах фундаментальные (а зачастую даже элементарные) функции по учету, не говоря уже про анализ.
Я приведу небольшой фрагмент из обзора рынка ERP-систем для представителей среднего и малого бизнеса, над которым сейчас работаю. Речь пойдет об одном ERP-решении всемирно известного бренда.
В рамках обзора я лично проводил тестирование целого ряда тиражируемых программных продуктов, причем тестирование с обязательным сопровождением и комментариями представителя. Нами был разработан некий бизнес-кейс, и предварительно мы показали его руководителям нескольких предприятий.
Первые радости
Мы подготовили некую бизнес-цепочку, которая отражала бы возможности системы с точки зрения логистики, финансов, взаимоотношений с клиентами, документооборота и других функциональных частей.
Оказалось, что ERP-система не в состоянии обеспечить работу более чем одного «своего» юрлица в одной базе. Причем, сразу нам об этом не сообщили — видимо, в надежде что «и так прокатит». Пришлось вскрывать попытку обмана. Демонстраторы вообще приехали в надежде, что получится замылить нам глаза всевозможными «признаками» и «аналитиками».
Что делать тем компаниям, у которых несколько своих юридических, лиц так и осталось загадкой. А ведь таких компаний в нашей стране подавляющее большинство (просто из-за особенностей национального налогообложения).
После того как выяснилось, что мы не сможем нормально работать от имени 2-х своих компаний, проведение тестирования стало почти бесполезным, но мы все же попробовали. Вдруг это только единственная проблема, а все остальное окажется на высочайшем уровне?
Нас откровенно смутило, когда презентующие оказали нам некоторое сопротивление, когда мы попросили отразить нашу цепочку на наших глазах, т.е. заносить данные при нас. Дело в том, что «продавцы» к нам приехали подготовленными, и все данные по нашей цепочке ввели в систему заранее. Нам же они хотели просто показать уже занесенные данные, видимо, опасаясь, что при по ходу могут возникнуть неприятности. И неприятности таки были…
Организация схемы «один клиент — несколько юрлиц» также оказалась невозможной. Во-первых, нас смутило, что названия самих клиентов и их юридических лиц находятся в одной и той же таблице. Неудобно, но не страшно. Главное — иметь возможность оценивать обороты, дебиторскую и кредиторскую задолженность по клиенту в целом, а не сидеть с калькулятором, складывая эти показатели по нескольким юридическим лицам, которые в реальности являются одни и тем клиентом.
Чем дальше в лес…
Самое интересное открылось, когда мы увидели на экране накладную, в которой в качестве плательщика было указано название самого клиента, а не юридического лица, которому выставлен счет. Это же совершенно нереально! Название клиента — это просто общее название вашего партнера. Как оно может фигурировать в накладных и счетах-фактурах? Мы попросили это исправить. После исправления юридическое лицо сразу перестало иметь какое-либо отношение к клиенту. Это значит, что при эксплуатации системы вам придется выбирать: или вы не сможете контролировать финансовые показатели по клиенту в целом, или вы не сможете формировать в системе первичные документы.
В ней также отсутствуют инструменты для передачи информации между сотрудниками различных подразделений. А ведь именно это место является наиболее проблемным в бизнесе. Вот пара ситуаций. Первая: менеджер по продажам выписал клиенту счет, тот его оплатил и хочет забрать товар. Как-то же менеджер должен сообщить кладовщику, что именно тот должен отгрузить, кому и когда? Вторая: менеджер выставил клиенту счет, тот его оплатил. Некоторых товарных позиций нет на складе и их необходимо закупить. Как менеджер по продажам сообщит закупщику, что именно тот должен закупить? Так вот, все эти инструменты для коммуникации сотрудников различных подразделений отсутствуют в ERP-решении. Нам посоветовали пользоваться привычной комбинацией телефон+email. А я вообще-то думал, что тиражируемые решения должны как раз избавлять предприятия от этих заморочек и давать бизнесу инструменты для организации цепочек в единой, прозрачной системе.
… тем больше дров
Затем нам решили похвастаться инструментом для планирования, где якобы менеджер по закупкам увидит в одном месте, что именно он должен купить. Каково же было наше удивление, когда мы обнаружили, что в чудо-планирование попадают товары, на которые клиентам просто выписаны счета. Видимо, разработчикам этого тиражируемого решения невдомек, что добрая половина счетов вообще остается неоплаченной. Товар будет закуплен, привезен на склад, но клиент его не заберет, т.к. передумает вообще даже счет оплачивать. Но даже если оплатит, это не сильно поможет. Потому как это самое планирование не очень-то связано с продажами. Да, менеджер по закупкам купит товар, но менеджер по продажам об этом никак не узнает (если, конечно, закупщик не забудет сказать ему об этом по телефону) да и клиент, под которого это закупалось, не получит резерва на складе, и этот товар запросто сможет кто-то другой продать и отгрузить.
Мы закупили товар, но при попытке отгрузить его клиенту не обнаружили его на складе… Оказалось, что система сама (!!!) списала со склада товар автоматически. Мне, конечно, объяснили что это так специально настроено, но выглядит весьма странно. Зачем нужны кладовщики, которые являются материально ответственными лицами — не понятно, если программа сама списывает товар.
Увидеть на экране счет-фактуру с товаром, учитываемым по серийным номерам, не получилось. Программа выдавала какие-то ошибки, и даже специалисты не могли понять, в чем проблема. С простым штучным товаром все вроде нормально, если не считать, что половина реквизитов в шапке счета-фактуры не заполняется. И это при том, что некоторые из незаполненных реквизитов вообще-то являются обязательными, и документ без этих реквизитов клиенту просто нельзя выдавать.
Возникла еще одна интересная ситуация: мы попытались запустить форму, которая отражает потребности в производстве (или закупке), но форма выдала ошибку и больше не запускалась. Оказывается, мы где-то указали не ту единицу измерения. Почему программа позволила это сделать — непонятно. Решить проблему так и не удалось.
Также не довелось нам увидеть внятную финансовую отчетность. Тут, видимо, к каждому клиенту индивидуальный подход (за его деньги, разумеется).
Функции управления договорами в системе просто нет. Да, есть некий список, но в нем банально не хватает обязательных для договоров реквизитов. Я уже не говорю, что нам не смогли показать, как система может автоматически формировать тексты договоров. Значит, придется пользоваться «дедовским» методом. Ну, MSWord в смысле.
Нет в стандартной поставке и встроенной системы управления проектами. Однако есть некое внешнее решение, с которым ERP интегрирована… Правда, стоит оно 14 тыс. евро. Как оно работает, пусть лучше ответят те, кто им пользуется.
Этот рассказ можно долго продолжать. Но есть ли смысл? Ау, тиражируемость, где ты?
Александр Попов, бизнес-консультант AVA Systems
И больше всего меня поразило, что участники обсуждали, как представлять данные, а не что представлять.
Почему-то производителей не беспокоит, что большая часть ERP-решений сегодня являются не тиражируемыми, а скорее эксклюзивными. Каждый клиент платит деньги за реализацию тех же самых функций, за которые платил предыдущий. И это при том, что в большинстве своем такие функции не являются чем-то изысканным. Поэтому, на мой взгляд, сначала необходимо решить вопрос именно тиражируемости, т.е. сделать так, чтобы бизнес-приложения работали сразу, а не через год после инсталляции (да и то не факт), а затем уже думать о том, как совершенствовать технологические платформы и средства представления данных.
«Счастье в коробке»
Все понимают, что тиражируемое решение — это хорошо со всех точек зрения. Это понимает и бизнес, и разработчики ERP-систем. Производители, конечно же, сразу взяли этот термин на вооружение, и во всех пресс-релизах «пиарят» его направо и налево. Это не важно, что тиражируемостью в большинстве случаев и не пахнет. Главное, чтобы клиент прочитал пресс-релиз об очередном «успешном внедрении».
Почему ни у кого не возникает мысли переписывать «под себя» MSWord или MSExcel, OpenOffice, Adobe Reader и т.д.? Все просто: потому что эти продукты работают сразу, то есть «здесь и сейчас» (plug&play). Да, есть нюансы, кто-то чем-то недоволен, но ведь в целом все работает! И никому не приходит в голову все это переписывать. Неужели кто-то думает, что если производители ERP-систем дадут бизнесу (по крайней среднему и малому) какие-то решения, которые тоже работают по принципу plug&play, то бизнес захочет их кромсать и переписывать? Конечно же, нет! Переписывание денег стоит, и не малых, и бизнес просто вынужден этим заниматься, потому как получает откровенно сырые решения. И даже не решения, а скорее некие платформы, на базе которых за свои же деньги уже пытается сделать решение. И так каждый клиент.
Понятно, что сравнивать ERP-систему с MSWord не совсем корректно. Однако я намеренно привел именно это сравнение. В любой ERP-системе 80% функционала абсолютно одинаково для всех клиентов. Потому что все компании работают примерно по одним и тем же законам, документооборот (в особенности по унифицированным формам) тоже не сильно отличается. Каждая компания — это не отдельно взятая микроэкономика со своими законами. Если бы это было так, то не существовало бы международных стандартов отчетности, все отчитывались бы по своим собственным принципам. Финансовые и логистические потоки во всех компаниях очень похожи. Так почему не дать бизнесу некое решение, где уже настроена и работает система управления затратами, логистикой, финансами? Но только так, чтобы это решение работало, чтобы были настроены бизнес-цепочки. Я уверен, что большая часть среднего и малого бизнеса с удовольствием возьмет готовый инструмент, вместо того чтобы изобретать свой собственный, ошибаясь на каждом шагу. Другой разговор, что в рамках цепочки нужно расставить сотрудников в рамках конкретной организации. Но одно дело — определить функциональное разделение доступа сотрудников в рамках существующей цепочки и совсем другое — изобретать эту цепочку.
Кому велосипед?
На практике более половины проектов по внедрению ERP-систем превращаются в изобретение велосипеда, когда на каждом проекте разработчики делают то же самое, что и на предыдущем. И это обстоятельство не мешает производителям витать в эмпиреях, устраивать семинары, на которых рассказывать потенциальным «жертвам» о том, как «корабли бороздят просторы вселенной», а затем, когда «клиент клюнул», за его же деньги реализовывать в своих продуктах фундаментальные (а зачастую даже элементарные) функции по учету, не говоря уже про анализ.
Я приведу небольшой фрагмент из обзора рынка ERP-систем для представителей среднего и малого бизнеса, над которым сейчас работаю. Речь пойдет об одном ERP-решении всемирно известного бренда.
В рамках обзора я лично проводил тестирование целого ряда тиражируемых программных продуктов, причем тестирование с обязательным сопровождением и комментариями представителя. Нами был разработан некий бизнес-кейс, и предварительно мы показали его руководителям нескольких предприятий.
Первые радости
Мы подготовили некую бизнес-цепочку, которая отражала бы возможности системы с точки зрения логистики, финансов, взаимоотношений с клиентами, документооборота и других функциональных частей.
Оказалось, что ERP-система не в состоянии обеспечить работу более чем одного «своего» юрлица в одной базе. Причем, сразу нам об этом не сообщили — видимо, в надежде что «и так прокатит». Пришлось вскрывать попытку обмана. Демонстраторы вообще приехали в надежде, что получится замылить нам глаза всевозможными «признаками» и «аналитиками».
Что делать тем компаниям, у которых несколько своих юридических, лиц так и осталось загадкой. А ведь таких компаний в нашей стране подавляющее большинство (просто из-за особенностей национального налогообложения).
После того как выяснилось, что мы не сможем нормально работать от имени 2-х своих компаний, проведение тестирования стало почти бесполезным, но мы все же попробовали. Вдруг это только единственная проблема, а все остальное окажется на высочайшем уровне?
Нас откровенно смутило, когда презентующие оказали нам некоторое сопротивление, когда мы попросили отразить нашу цепочку на наших глазах, т.е. заносить данные при нас. Дело в том, что «продавцы» к нам приехали подготовленными, и все данные по нашей цепочке ввели в систему заранее. Нам же они хотели просто показать уже занесенные данные, видимо, опасаясь, что при по ходу могут возникнуть неприятности. И неприятности таки были…
Организация схемы «один клиент — несколько юрлиц» также оказалась невозможной. Во-первых, нас смутило, что названия самих клиентов и их юридических лиц находятся в одной и той же таблице. Неудобно, но не страшно. Главное — иметь возможность оценивать обороты, дебиторскую и кредиторскую задолженность по клиенту в целом, а не сидеть с калькулятором, складывая эти показатели по нескольким юридическим лицам, которые в реальности являются одни и тем клиентом.
Чем дальше в лес…
Самое интересное открылось, когда мы увидели на экране накладную, в которой в качестве плательщика было указано название самого клиента, а не юридического лица, которому выставлен счет. Это же совершенно нереально! Название клиента — это просто общее название вашего партнера. Как оно может фигурировать в накладных и счетах-фактурах? Мы попросили это исправить. После исправления юридическое лицо сразу перестало иметь какое-либо отношение к клиенту. Это значит, что при эксплуатации системы вам придется выбирать: или вы не сможете контролировать финансовые показатели по клиенту в целом, или вы не сможете формировать в системе первичные документы.
В ней также отсутствуют инструменты для передачи информации между сотрудниками различных подразделений. А ведь именно это место является наиболее проблемным в бизнесе. Вот пара ситуаций. Первая: менеджер по продажам выписал клиенту счет, тот его оплатил и хочет забрать товар. Как-то же менеджер должен сообщить кладовщику, что именно тот должен отгрузить, кому и когда? Вторая: менеджер выставил клиенту счет, тот его оплатил. Некоторых товарных позиций нет на складе и их необходимо закупить. Как менеджер по продажам сообщит закупщику, что именно тот должен закупить? Так вот, все эти инструменты для коммуникации сотрудников различных подразделений отсутствуют в ERP-решении. Нам посоветовали пользоваться привычной комбинацией телефон+email. А я вообще-то думал, что тиражируемые решения должны как раз избавлять предприятия от этих заморочек и давать бизнесу инструменты для организации цепочек в единой, прозрачной системе.
… тем больше дров
Затем нам решили похвастаться инструментом для планирования, где якобы менеджер по закупкам увидит в одном месте, что именно он должен купить. Каково же было наше удивление, когда мы обнаружили, что в чудо-планирование попадают товары, на которые клиентам просто выписаны счета. Видимо, разработчикам этого тиражируемого решения невдомек, что добрая половина счетов вообще остается неоплаченной. Товар будет закуплен, привезен на склад, но клиент его не заберет, т.к. передумает вообще даже счет оплачивать. Но даже если оплатит, это не сильно поможет. Потому как это самое планирование не очень-то связано с продажами. Да, менеджер по закупкам купит товар, но менеджер по продажам об этом никак не узнает (если, конечно, закупщик не забудет сказать ему об этом по телефону) да и клиент, под которого это закупалось, не получит резерва на складе, и этот товар запросто сможет кто-то другой продать и отгрузить.
Мы закупили товар, но при попытке отгрузить его клиенту не обнаружили его на складе… Оказалось, что система сама (!!!) списала со склада товар автоматически. Мне, конечно, объяснили что это так специально настроено, но выглядит весьма странно. Зачем нужны кладовщики, которые являются материально ответственными лицами — не понятно, если программа сама списывает товар.
Увидеть на экране счет-фактуру с товаром, учитываемым по серийным номерам, не получилось. Программа выдавала какие-то ошибки, и даже специалисты не могли понять, в чем проблема. С простым штучным товаром все вроде нормально, если не считать, что половина реквизитов в шапке счета-фактуры не заполняется. И это при том, что некоторые из незаполненных реквизитов вообще-то являются обязательными, и документ без этих реквизитов клиенту просто нельзя выдавать.
Возникла еще одна интересная ситуация: мы попытались запустить форму, которая отражает потребности в производстве (или закупке), но форма выдала ошибку и больше не запускалась. Оказывается, мы где-то указали не ту единицу измерения. Почему программа позволила это сделать — непонятно. Решить проблему так и не удалось.
Также не довелось нам увидеть внятную финансовую отчетность. Тут, видимо, к каждому клиенту индивидуальный подход (за его деньги, разумеется).
Функции управления договорами в системе просто нет. Да, есть некий список, но в нем банально не хватает обязательных для договоров реквизитов. Я уже не говорю, что нам не смогли показать, как система может автоматически формировать тексты договоров. Значит, придется пользоваться «дедовским» методом. Ну, MSWord в смысле.
Нет в стандартной поставке и встроенной системы управления проектами. Однако есть некое внешнее решение, с которым ERP интегрирована… Правда, стоит оно 14 тыс. евро. Как оно работает, пусть лучше ответят те, кто им пользуется.
Этот рассказ можно долго продолжать. Но есть ли смысл? Ау, тиражируемость, где ты?
Александр Попов, бизнес-консультант AVA Systems
Опубликовано 13.04.2010