Автоматизация управленческой отчетности. Ошибки проектной команды при анализе отчетности.

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

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

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

Здесь очень много подводных камней:

  • Заказчик и Исполнитель могут понимать разный смысл под «Перечнем отчетов». Например, возьмем отчет о продажах. Для Заказчика может оказаться естественным, что продажи можно анализировать в разрезе товара, контрагентов, групп товара, еще множества параметров. Причем, перечень таких параметров сейчас сформировать нельзя, «мало ли как нам захочется проанализировать». Часто для этой цели полагаются на настраиваемые отчеты, с надеждой на то, что удастся настроить под пока неопределенные требования. Может получиться, а может и нет. Все возможные комбинации такого отчета для Заказчика могут являться одним отчетом, а могут быть комплектом отчетов (о продажах). Впрочем, как и для Исполнителя. Все зависит от восприятия отдельных людей. Как минимум, перечень возможных аналитик стоит оговорить заранее. Это как минимум!
  • Заказчик может утверждать, что не может сейчас сделать такой ограниченный перечень. Это сразу должно насторожить. Скорее всего, он еще сам не полностью понимает, какие отчеты ему потребуются. В этом случае лучше ограничиться тем перечнем, который он может точно сформировать сейчас, а остальные отчеты вынести за рамки. «Будет понимание – будем обсуждать». Исключением может являться случай, когда предметом работ и является разработка состава и структуры отчётности, но это уже консалтинг, и находится за рамками рассматриваемой темы.
  • Под одним и тем же наименованием отчета разные сотрудники могут понимать разное содержимое
  • И т.п. Наверняка Вы сталкивались и с другими причинами.

 

 
 Случай из практики: 

К компанию Заказчика пришел новый руководитель отдела продаж. При диалоге с ним относительно отчетов по продажам выяснилось, что ничего особенного для него не требуется, «только простейшие данные о продажах». Ну, раз простейшие, все решили, что стандартные отчеты во внедряемой системе (это была 1С) должны эти требования покрыть.
В последствии выяснилось, что ранее этот руководитель работал в компании, где использовалась заказная система, разработанная под требования этой компании. Конечно же, он не вникал, что там разрабатывалось специально, что уже было, для него это все было естественно. Так вот, самым первым требованием для него было отображение в отчете о продажах прибыли по каждому менеджеру. Такой отчет из внедряемой системы получить было можно, но… это был уже совсем другой отчет. Т.е. хотелось иметь в одном отчете то, что во внедряемой системе можно получить двумя отдельными отчетами. И договариваться о компромиссах он был не намерен.

 

 

 knopka

 Совет:

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

 

 

В документации с требованиями не описана структура каждого отчета

Думаю, уже стало очевидно, что каждый отдельно взятый вариант отчета должен быть подвержен анализу. Как это сделать? Очень просто: берем полученный перечень, и начинаем рассматривать каждый отчет по порядку. По каждому отчету разбираем каждую колонку в отдельности, не зависимо от кажущейся простоты и очевидности.

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

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

 В документации с требованиями не описаны дополнительные требования к отчетам

Не всегда бывает важно, но при обсуждении системы отчетности стоит обратить внимание и на такие моменты:

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

В документации с требованиями не содержатся образцы форм отчетов, либо не анализируются данные, в них содержащиеся

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

 

 Случай из практики: 

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

И подобных случаев встречается очень много!

 

Так что не поленитесь собрать образцы всех планируемых отчетов, пронумеровать и приложить их к описанию структуры отчетов.

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

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

 

Если учесть все вышеизложенное, мы получим вполне приличный набор информации:

  • Перечень отчетов
  • Описание каждого отчета
  • Образцы отчетов

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

  • Встречаются экономические показатели, рассчитанные по базе распределения, которая не является формализованной, т.е. в ее определении есть большая доля субъективизма конкретного сотрудника (по сути он ее не рассчитывает, а задает явно из каких-то одному ему ведомых предположений, либо учетом погрешностей, находящихся за границами учета).
  • В одной и той же колонке, в зависимости от ситуации, может выводиться совершенно разная информация. А иногда даже вписываться какой-нибудь комментарий при отсутствии информации. В Excel это конечно просто, а при автоматизации такого неформализованного подхода могут возникнуть трудности
  •  Могут быть данные, которые вообще никому не нужны (просто от того, что они остались там исторически). Одно дело, когда это не влияет на трудоемкость при разработке отчета. Но если это достаточно сложно для системы, то лучше такие данные исключить.
  • Встречаются показатели, алгоритм расчета которых вообще никто не может описать. «Нам так сделали программисты». Не понимаю, причем тут программисты и какие управленческие решения можно принимать, опираясь на такие цифры?
  • Очень опасная штука: часть данных, выводимая в отчет, при ближайшем изучении может оказаться за границами текущего проекта, либо его этапа. Например, потребовать ведения хозяйственных операций, которые никто раньше не делал. Самое печальное, может случиться и так, когда никто и не захочет вводить в систему необходимые данные таким сложным способом, который может потребоваться. Например, всю жизнь просто вводили цифру в ячейку Excel и все, а теперь нужно оформлять целый документ в программе и пр. В результате может возникнуть следующая  дилемма: либо не будет такого отчета, что приведет к невозможности реализовать требования Заказчика, либо потребуется существенное усложнение учета, что приведет к негативу от конечных пользователей (никому не хочется усложнять себе жизнь). Что делать в подобной ситуации, надо решать в каждом случае персонально. Решения могут быть различными: оставить данный участок за границами автоматизации, изменить методику учета, изменить отчет и пр. Главное, чтобы задача  была сделана своевременно, еще на этапе анализа требований, а не на стадии активной разработки. Негатив в последнем случае гарантирован.
  • Тот, кто анализирует отчет, обычно ожидает, что если из названия колонки очевидно, что там должно содержаться, то так оно и есть. Да, и даже в это не надо верить! Лучше не стесняться задавать простые вопросы, времени на это много не потребуется, а уверенности в правильности взаимного понимания прибавится. К сожалению, некоторые Заказчики воспринимают простые вопросы от консультантов как недостаток компетенции. «Зачем Вы задаете такие вопросы, это же очевидно, Вы и так должны это знать, да еще и нас учить» — возможно, кому-то приходилось слышать подобное. На самом деле, это свидетельствует о недостаточном опыте в проектах автоматизации как раз человека со стороны Заказчика. «Крупный успех составляется из множества предусмотренных и обдуманных мелочей»  — хорошая фраза В.Ключевского.
  • Бывают и более сложные случаи. Например, выдвигаются требования к отчетности, возможность формирования которой будет возможна только тогда, если изменить саму методику учета, сложившуюся в компании. А этого могут и не захотеть. «Ведь сейчас как-то в Excel мы ее делаем, почему программа не может?». Бывает даже такое, что устоявшаяся система отчетности не всегда корректна (иногда Заказчик обижается, но когда ему это объясняешь, понимает).  В последнем случае, кстати, будут упираться до последнего. Ведь, если задуматься, в некорректной отчетности (методически), вполне может быть чья-то вина (либо недостаток квалификации). И этой вины сотрудник боится гораздо раньше, чем кто-то ему предъявит претензии (обычно никто и не предъявляет). На практике не припомню ни одного случае, чтобы сотрудников ругали за методически некорректно построенную отчетность, ведь разрабатывать методики – это обязанность компании, т.е. как минимум лиц, обладающими соответствующими полномочиями и компетенцией. Поэтому, когда такую обязанность спускают до рядового сотрудника, он делает так, как позволяет его опыт и знания, а также ограничения в доступности актуальной информации. Еще спасибо сказать должны. Но он все равно боится, так устроено большинство людей, не каждый может сказать вслух: «по-другому я не смог придумать, хотя понимаю, что это не совсем правильно». Такие люди стараются как можно меньше рассказывать, чем они занимаются, как строят отчеты, а иногда даже являются источником саботажа. С ними надо найти общий язык, для чего потребуются развитые коммуникативные навыки консультанта.

Компетенции аналитиков недостаточно, чтобы анализировать управленческую отчетность 

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

 knopka

 Вывод:

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

 

В заключение раздела я обещал смоделировать некое идеальное состояние  системы отчетности Заказчика,  при котором автоматизация может пойти достаточно гладко. Одно расстраивает – такое состояние на практике встречается крайне редко:

  • Компания имеет документально утвержденную систему управленческой отчетности (например, положение об управленческой отчетности).  Причем, это не формальный документ, а реально работающий, который своевременно обновляется и поддерживается в актуальном состоянии. В документе прописаны:

    • Виды отчетов и их структура
    • Образцы отчетов
    • Регламенты предоставления
    • Ответственные лица
    • Для всех составляющих отчетов понятны методы сбора информации
    • Экономический смысл всех показателей понятен
  • Для сбора информации применяются какие-либо автоматизированные способы
  • Планов по изменению методик формирования системы управленческой отчетности нет, планируется только ее автоматизация

 

Опубликовать в Facebook
Опубликовать в Google Plus
Опубликовать в LiveJournal
Опубликовать в Одноклассники

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *