Страница рассылки  Написать автору Форум рассылки

Когда начинается проект автоматизации, опытные консультанты обязательно зададут вопрос об отчетности. Ведь они-то знают, какие проблемам могут возникнуть, если пустить вопрос на самотек. Однако, на практике Заказчик часто склонен упрощать задачу управленческой отчетности. Давайте попробуем разобраться, что ими движет? А движет ими ряд убеждений (или заблуждений), основанных либо на собственном представлении о простоте информационных систем (чисто субъективно), либо на впечатлениях от рекламных семинаров с красочными картинками и радужными обещаниями продавцов программных продуктов. Бывает, что сказывается и их прошлый опыт успешного внедрения программных продуктов на другом предприятии (на прошлой работе, например), но где они были не активными участниками процесса, а лишь конечными пользователями, получившими готовый результат. Соответственно, не владели информацией о трудоемкости работ, сроках и бюджетах, применяемых подходах. Рассмотрим наиболее распространенные заблуждения, которых следует остерегаться.

«Давайте пока не будем думать об отчетности. Сначала сделаем систему, потом займемся отчетами».

При этом в план проекта отчетность предлагается включить, да еще и оценить стоимость ее реализации. Определенно, в этом месте надо задуматься. По статистике, отчетность может «съесть» до 10-50, а то и больше процентов бюджета. Т.е. вариативность весьма высока. Вы готовы так рисковать? Скорее, нет. Тогда надо внести ясность. Самое логичное решение в данном случае, вынести вопрос с отчетностью либо в отдельный проект, либо отдельный этап, имеющий конкретный результат в виде системы отчетности. Конечно же, давать оценку такому этапу работ невозможно. Это нужно объяснять. К сожалению, не всегда просто. Часто Заказчику представляется, что отчетность это очень простая задача для программы, сделать ее быстро и стоить должна совсем не дорого. Это может быть справедливо только в одном случае: когда в компании Заказчика выполняется сразу несколько условий, о которых поговорим позже.

Случай из практики: Давайте рассмотрим пример из жизни. Разработана система для автоматизации торговой деятельности (продажи мебели). Менеджеры начали работать, все хорошо. Доходит очередь до отчетов. И тут выясняется, что важным отчетом является отчет по прибыли за квартал, т.к. по нему считают квартальные премии. А себестоимость товара определяется как стоимость закупки плюс затраты на доставку из-за границы, которые распределяются по товару, купленному за прошедший квартал. Причем сумма таких затрат собирается специально к отчетному периоду неким сотрудником, одному ему известным методом. Распределение он делает по группам товаров, а не по каждому товару в отдельности. Понятия групп товаров в предыдущей системе не имелось, и этот сотрудник решал данную задачу в Excel. Да еще и укрупненно. Далее выясняется, что один и тот же товар может быть куплен как внутри страны, так и за границей. Пытаясь смоделировать подобный учет в новой системе, мы начинаем понимать, что не предусматривали такое. Да и не хочется такой вариант моделировать, уж очень он «кривой». Итак, какие коллизии возникли при анализе всего одного показателя одного отчета? Возникает целый ряд вопросов: Необходимо предусмотреть разделение товара на соответствующие группы, кто-то должен будет это контролировать; Необходимо предусмотреть распределение затрат по группам (а может по каждому товару?) Возникает необходимость учитывать партии товара. И дальше возникают более сложные вопросы: почему затраты распределяют на весь товар, а не на конкретную партию поставки? Философский вопрос: А почему вообще данный момент не «всплыл» при моделировании системы? А сколько еще «интересного» мы узнаем в ближайшее время при анализе отчетности (других отчетов)? Скорее всего, подобная история закончится рядом встреч с обсуждением методик ведения учета. И наверняка не сразу будет достигнуто единое мнение. А потом потребуется доработка системы, внесение изменений в пользовательские инструкции… А еще в голове зарождается опасение, что в отчетности Заказчика будет много странностей (судя по началу J), которые придется долго обсуждать, предлагать альтернативные варианты (не потому, что сложно сделать, а потому как методы формирования отчетности представляются сомнительными с экономической точки зрения). К чему это приведет? В первую очередь, это время. И, скорее всего, не малое. Возможна ситуация, что автор старой отчетности может стать противником новой системы и будет всем рассказывать, что вот у него с отчетами было хорошо, а теперь ничего непонятно! Система не продуманная, сложная и т.п. Вот он в Excel делал все быстро и понятно. И вероятность того, что ему будут верить больше, чем Вам, весьма высока. Чтобы доказать обратное, потребуется немало времени и усилий. И нервы он начнет портить как раз вовремя, в начале опытной эксплуатации:). А раз мы включили отчетность в состав основных работ по проекту, то никуда уже не денешься. Продолжение истории предсказуемо... Вот так, с простого отчета может начаться процесс изменения архитектуры системы и длительные обсуждения методологических вопросов.

Совет: Вывод: если Заказчик не готов говорить об отчетности в момент инициации проекта (точнее, постановки целей и задач), выносите отчетность за рамки проекта. Надо понимать, что, скорее всего, полученная система будет подвергнута доработкам, когда Вы доберетесь до отчетов. Они непременно скажутся на архитектуре. Соответственно, понимание требований к будущей отчетности перед проектированием архитектуры может оптимизировать работы по проекту в целом. Надо отметить, что чем грамотнее архитектор системы, тем более универсальной будет полученная система изначально, проще модифицироваться и масштабироваться.

«Нам необходима такая система отчетности, в которой можно самим настраивать отчеты, как нам потребуется»

Довольно распространенный случай. Как ни странно (хотя... почему странно? J), некоторые менеджеры по продажам программных продуктов, когда слышат подобное от потенциального клиента, радостно восклицают: «Да-да, у нас именно такая система! Можно настроить любые отчеты!». Знали бы они, что потом приходится выслушивать специалистам по внедрению. А все почему? Продали плохую систему? Плохие продавцы? Неадекватный Заказчик? Вовсе не обязательно. На практике встречаются случаи, когда одна и та же система в похожих условиях для одного Заказчика удовлетворяет его требования к отчетности, а для другого совсем нет. Причина кроется во множестве факторов: привычка, менталитет, более высокие требования к аналитике, нестандартное мышление руководителей, прошлый опыт использования иных систем и т.п.

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

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

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

«Наша система отчетности сейчас реорганизуется/актуализируется/прорабатывается»

Иногда так получается, что проект автоматизации совпадает с внутренними организационными изменениями в компании-Заказчике. Это абсолютно нормально, так как инициатива проекта автоматизации часто является следствием организационных изменений (в структуре компании, методиках учета и пр.).

Если никак не разделять данные процессы, проект автоматизации будет втянут в текущие изменения компании. Чем это грозит? Тем, что вместе с изменениями часто меняются и требования к системе. Порой настолько быстро, что не угнаться. Как результат, резкое увеличение затрат. Как лучше поступить в подобной ситуации?

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

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

Так вот, второй путь это и есть эффективная работа в условиях изменений.

Конечно, есть еще и третий путь – это когда есть бездонный бюджет и никто команду не торопит. Если Вам так везет, то дальше можно не читать:)

Совет: При необходимости работать в условиях быстрых изменений в компании Заказчика, надежным способом избежать финансовых убытков является выполнение трех условий: Четкая формулировка требований к результату Достижение результата в планируемые сроки Доведение результата до пользователей (его успели использовать на практике). Если хотя бы один пункт не будет выполняться, Заказчик всегда будет пытаться заставить Вас поработать на его благо бесплатно.

«Давайте Вы не будете решать, что корректно, а что нет, нам так надо и все!»

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

Случай из практики: Был такой случай в крупной торговой компании. Одна сотрудница в отделе продаж занималась сбором отчетности. Один из отчетов она делала целых 2 недели. И так каждый месяц. Когда добрались до отчетности, мне стало интересно, что же за отчет такой… Стали разбираться. Оказалось, что это взаиморасчеты с покупателями в разрезе брендов. Спрашиваю «а Вы что, отгружаете товар разных брендов разными накладными?», Нет, говорит, все вместе. Потом сидит и разделяет. «Ну а если клиент частично заплатил, то за какой товар по Вашему, он заплатил?» Подумав, отвечает: «ну.. сама определяю». Странный какой отчет, подумал я и решил спросить, кто же это его требует и какие управленческие выводы из него делает. Подхожу к начальнику отдела. Оказывается, он этот отчет просто берет, и пересылает директору, сам не смотрит. Говорит, «директор требует». А перед обсуждали все отчеты, которые нужны директору и ничего похожего там не упоминалось. Подхожу к директору, спрашиваю, для чего ему такой отчет. Директор и говорит, что присылают такой, но он ей не нужен, просто не обращает внимания, может кто-то пользуется. В результате наблюдалась комичная ситуация: человек тратит 50% времени на отчет, который никому не нужен. А как же такое получилось, спрашиваю? Оказалось, что несколько лет назад, когда фирма только начинала работать, товар отгружали раздельно по брендам, оттуда и пошло. В общем, жизнь того сотрудника сильно поменялась J Мне вообще непонятно, как можно готовить отчетность для кого-то, если не понимаешь экономический смысл обрабатываемых данных, и какие решения можно принимать опираясь на эти данные! В последствии я еще пару раз сталкивался с требованием анализировать взаиморасчеты в разрезе товарных групп. И всегда их делали сотрудники с недостаточной экономической подготовкой. Бесполезная трата времени. При более глубоком «копании» в корень причин такого странного анализа, можно было предположить, что они пытались анализировать оборачиваемость товара. Да, да, именно так. Ведь фирма оптовая, и когда она отдает товар под реализацию в розничные сети с условием оплаты за поставку по факту продажи, отталкиваясь от этого срока можно анализировать оборачиваемость (товар ушел розничному покупателю). Косвенно да, но это настолько искаженная информация! Там масса факторов, включая умение вести розничный бизнес отдельных покупателей. И далеко не факт, что время продажи товара соответствует сроку оплаты за него, ведь есть еще и отсрочки платежа, которой могут пользоваться, а могут и нет. Тогда уже лучше с магазинами договориться было, чтоб отчеты о розничных продажах присылали. Кстати, в одном книжном издательстве так и сделали, формируя рейтинги продаж книг не от факта оптовых продаж, а от продажи товара уже через розничные сети (с которыми договорились о предоставлении данной информации).

Вывод: Не нужно лениться анализировать смысл формируемой отчетности. В ней может содержаться масса ошибок. Главное, чтобы это делали люди с соответствующей компетенцией. Иначе, автоматизировать такую отчетность не получится никогда. Если есть разумные аргументы, что существующие подходы имеет смысл поменять, всегда можно это объяснить, обсудить с руководством Заказчика и найти оптимальное решение!

Случай из практики: Приведу еще пример. Крупная государственная структура. Есть утвержденные требования к формам отчетности. К сожалению, требования к формам есть, а как заполнять данные в конкретных колонках, требований нет. На момент анализа отчетности на предмет автоматизации она формировалась в Excel. Смотрю на этот Excel – просто художественное произведение. В одной и той же колонке то цифры, то примечания, то вообще непонятно что, но точно не соответствующее заголовку колонки. Да еще и объединенные ячейки местами – там, где значения одинаковые. В общем, формализация ввода данных отсутствовала. Начинаю объяснять, что для автоматизации в любом случае необходимо выработать четкие правила, откуда эти данные будут браться в отчет. Молодая и симпатичная девушка (вылитая блондинка), занимающаяся данным отчетом большую часть своей трудовой деятельностью заявляет: «отчет будет выглядеть так, как я его делаю, это не обсуждается и не ваше дело решать как правильно». Вот так вот… Ну что тут делать – «за руку» и к ее начальнику, чтобы тоже поудивлялся творчеству своего сотрудника. И ведь он искренне удивлялся, почему раньше об этом не думал. В результате девушка пошла думать над едиными правилами. Никогда не нужно бояться или стесняться обсуждать не очевидные или нелогичные вещи. Иначе задача выполнена не будет.

«Все отчеты из Excel необходимо перевести в программу Х»

• Существуют действительно сложные таблицы, требующие много времени для формирования и обработки. Явно напрашивается автоматизация.
• Существуют небольшие таблицы, в которых сотрудники обрабатывают информацию, по смыслу находящуюся явно за рамками планируемого проекта;
• Существуют таблицы, автоматизация которых потребует от пользователя потратить в разы больше времени на регистрацию хозяйственных операций в системе, т.е. автоматизация только усложнит жизнь;
• Существуют таблицы, содержащие второстепенную (малозначимую) информацию, не используемую для принятия решений. И в системе ее видеть не желают;
• И еще возможны варианты…

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

Случай из практики: Небольшая строительная компания. Идет проект по автоматизации учета: затраты, производство, бухгалтерия и пр., в том числе управленческая отчетность. В команде витает установка, что все, что ведут в Excel, непременно надо перевести в систему. Аналитик обнаруживает таблицу Excel, в которой специалист по аренде спецтехники записывает номера арендованных автомобилей и срок арены, чтобы потом не забыть возвратить или продлить сроки, а также контролирует оплату. Данного сотрудника ни сколько не напрягает вести такую таблицу, на него никто не жалуется, времени практически не тратит. Кроме него эта информация никому не нужна. Прикинув, как можно автоматизировать его деятельность, становится очевидным, что если он раньше менял цифру в одной ячейке, то в системе придется вводить целый документ, регистрирующий операцию. Теоретически правильно, но… зачем? Зачем пытаться перевести эту таблицу в учетную систему? Если нам потребуется знать затраты по аренде спецтехники, то это будет учет затрат по определенной статье затрат. Если потребуется отдельно выделять взаиморасчеты, то и для этого можно выделить аналитику в учете взаиморасчётов, например, по поставщикам. Другое дело, если Заказчик сам попросил такой учет, потому что у него 3000 единиц техники в аренде и надо планировать их территориальное перемещение по объектам. Но это уже логистическая задача, и совсем другая история.

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

«Хотим иметь такой один большой отчет, чтобы в нем было все сразу»

Вариант первый: Когда-то, когда бизнес только начинался, отчеты были совсем простые. Как правило, это был один или два отчета, которыми пользовался директор. Часто он и делал их сам. Со временем эта функция перешла к выделенному сотруднику, который готовил отчетность для директора. Бизнес рос, количество вопросов, на которые директор хотел получать ответы, тоже росло. Для ответа на один вопрос обычно придумывают соответствующий показатель. Естественное желание человека – не придумывать новый отчет, а просто расширить существующий еще одной или парой колонок. Все в принципе удобно. Так отчет постепенно обрастает множеством информации, порой не очень хорошо согласованной между собой. С другой стороны, с дальнейшим ростом бизнеса появляются и новые потребители этих отчетов (руководители разных уровней), которых интересует только информация, нужная непосредственно им. В результате по компании начинают «ходить» отчеты, в одну часть которых смотрят одни люди, в другую другие. И так до тех пор, пока не придет понимание, что отчет призван отвечать на конкретный вопрос, от которого зависит принятие управленческих решений.

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

Зачем в отчете о продажах выводить дебиторскую задолженность? Истинная причина может быть только одна – привычка. Сначала смотрю в одну часть отчета, потом в другую, решая совершенно разные задачи. Нет никакой связи между этими показателями. И зоны ответственности совершенно разные (т.е. обычно за эти показатели отвечают разные люди). Чем поможет такой отчет? Хотим запретить продавать товар при превышении покупателем лимита по задолженности? Так надо и возложить контроль на учетную систему, чтобы не давала оформлять документ продажи, причем здесь отчет?

Во-первых, их гораздо сложнее разрабатывать. Их сложнее модернизировать. В них по определению закладываются ограничения по аналитике. Например, как в вышеприведенном примере: отчет будет иметь смысл только в группировке по покупателям. А продажи как раз надо анализировать в различных разрезах. Таким образом, настройки отчета пользователем заведомо ограничиваются. Чтобы пользователь не смог сделать настройки, противоречащие здравому смыслу, тоже придется поработать (и отчет с технической точки зрения станет еще сложнее).

«Надо купить программу Х — там все отчеты уже есть!»

Вообще, это такая категория клиентов, с которыми надо держаться осторожно. Ни в программе «Х», ни в программе «2Х», всех отчетов, необходимых в более-менее крупной компании, не будет. Точнее, что-то подобное возможно и будет. Но, как показывает практика, тема отчетности – это отдельная история в любом проекте. Если этим пренебречь и понадеется на то, что в новой купленной программе будут все отчеты, как их хотят видеть, впоследствии можно сильно разочароваться.