Процесс строительства здания трудно представить без этапа проектирования. Вместе с тем, при внедрении на предприятии информационной системы часто обходятся без серьёзной проработки проекта. В этом случае внедрение заканчивается разочарованием заказчика в исполнителях и в эффективности ИТ-технологий в целом. В статье описана методика формирования проекта ИС, обеспечивающая реализацию главного предназначения информационной системы – быть инструментом системы управления компанией.
Известно, что внедрение информационной системы (ИС) на предприятиях часто заканчивается разочарованием заказчика в исполнителях и в эффективности ИТ-технологий в целом. Одна из главных причин неудачных внедрений – это слабая проработка проекта ИС на этапе управленческого консалтинга. В результате ИС оказывается в недостаточной степени интегрирована в общую систему управления компанией (СУ), оставаясь, в лучшем случае дорогостоящим калькулятором для ведения управленческого и регламентированного учёта.
Совершенно другой результат можно получить, приняв во внимание тот факт, что ИС не является для заказчика самоценным продуктом, а должна стать инструментом системы управления предприятием на всех её уровнях, начиная со стратегии и заканчивая процедурами. Это свойство ИС должно быть обеспечено на первом шаге внедрения ИС - этапе управленческого консалтинга.
Нужно сразу оговориться, что полный проект ИС включает в себя ряд вопросов, находящихся за рамками компетенции управленческого консультанта. В статье речь пойдёт о методике разработки тех документов проекта, которые формируются на этапе управленческого консалтинга, а под «проектом ИС» подразумевается совокупность этих документов.
Рассмотрим подробнее методику реализации этого этапа в разрезе основных задач, решаемых ИС.
В общем случае ИС должна обеспечивать решение следующих задач:
1. Сбор первичных данных о деятельности компании и представление их в удобном для анализа виде
2. Управленческий и регламентированный учёт
3. Поддержка документооборота
4. Планирование и прогнозирование
5. Поддержка бизнес-процессов
В начале 2000-х годов автор работал в оптово-розничной компании, использовавшей систему учёта товарно-материальных ценностей собственной разработки. К тому моменту в системе насчитывалось более 700 отчётов, в которых рассчитывались несколько тысяч показателей. Поскольку практики описаний отчётов не было и разобраться в этом хаосе не представлялось возможным, каждый новый менеджер заказывал себе 10-15 новых отчётов, мобилизуя на эту работу программистов всеми доступными методами. Знакомая картина непозволительного расходования ресурсов?
Возникает вопрос: как на этапе проектирования составить необходимый и достаточный список показателей, которые затем будут представлены в отчётах ИС, предназначенных для принятия управленческих решений? Поскольку мы определились с тем, что ИС должна стать инструментом СУ, ответ на этот вопрос очевиден: в ИС должны, в первую очередь, рассчитываться показатели, которые используются в СУ для контроля деятельности предприятия, подразделений, сотрудников. Если в СУ этот список не определён, это необходимо сделать, воспользовавшись одной из известных методик, например, методикой Balanced Scorecard (BSC), предназначенной для организации реализации стратегии компании. Одним из результатов применения методики BSC является система показателей, сконструированная на основе выбранной стратегии. Таким образом, реализуя в ИС систему показателей BSC, мы обеспечиваем интеграцию ИС и СУ на уровне стратегии.
Для решения задачи ИС, перечисленной в списке под номером 1, системы показателей недостаточно. Необходимо также предусмотреть сбор первичных данных, на основе которых эти показатели будут рассчитываться. Решения о том кто, когда, по какому событию, при каких условиях регистрирует эти данные в ИС, должны быть зафиксированы в документах проекта: ролях пользователей, бизнес-процессах, регламентах, требованиях к функционалу. Не является также излишней проработка форматов отчётов, в которых показатели будут представлены. Если этот вопрос будет отдан на откуп программисту, заказчик может быть неприятно удивлён результатом в тот момент, когда обязательства внедренцев по этому вопросу будут уже выполнены. Активное участие заказчика в определении форматов является залогом получения результата в действительно «удобном для анализа виде».
Для того, чтобы система управления по показателям стала эффективным инструментов СУ, она должна быть проработана на процедурном уровне. Поэтому процедуры, предусмотренные методикой Balanced Scorecard, должны быть формализованы на этапе разработки бизнес-процессов компании.
Вообще говоря, задача ИС, обозначенная выше под номером 2, является частным случаем задачи N 1. Управленческий и регламентированный учёт – это также процессы сбора первичных данных и представления информации для анализа сотрудниками компании и налоговыми органами, соответственно. Однако, на этапе управленческого консалтинга вопросы учёта необходимо рассмотреть отдельно, так как они должны найти специфическое отражение в проекте ИС.
В первую очередь, это касается описания финансово-юридической структуры компании и соответствующего документооборота. Зачастую, даже небольшие российские компании представляют из себя своего рода холдинги, объединяющие несколько юридических лиц, связанных коммерческими отношениями. Задача ИС заключается в формировании регламентной отчётности юридических лиц и управленческой отчётности холдинга с требуемой детализацией. В современных ИС имеются развитые средства реализации финансово-юридических структур холдингов, но для настройки этих средств, структура и документооборот должны быть проанализированы и описаны на этапе формирования проекта. Таким образом будет достигнута интеграция ИС с финасово-юридическим уровнем СУ предприятием.
Другой вопрос учёта, который должен быть проработан на этапе управленческого консалтинга, - это учётная политика. Если учётная политика регламентированного учёта определяется действующим законодательством, то управленческая учётная политика разрабатывается самим предприятием и должна соответствовать его целям, стратегии, структуре управления. Управленческая учётная политика фиксируется в документе общепринятой структуры и является составной частью проекта ИС.
В процессе проектирования будущей системы учёта должны быть также проработаны требования по безопасности и защите учётной информации.
Наконец, для обеспечения преемственности новой системы учёта с уже накопленной информацией, должны быть проработаны вопросы переноса справочников, остатков, документов в новую ИС. Фактически, речь идёт об обеспечении непрерывности информационной поддержки системы управления предприятием.
Для обеспечения решения третьей из перечисленных задач ИС, а именно поддержки документооборота, на этапе управленческого консалтинга должен быть проанализирован и структурирован документооборот компании. Обычно выделяют следующие подсистемы документооборота:
- Поддержка финансово-юридической структуры
- Движение ТМЦ
- Обмен сообщениями, документами
- Формирование планов, задач. Отчётность по ним
- Создание, согласование, утверждение документов
- Регистрация и контроль исполнения входящих и исходящих
- Организация архива документов
На этапе управленческого консалтинга принимается решение о том, какие подсистемы документооборота будут поддерживаться ИС и формируется их описание, которое должно найти своё отражение в документах проекта ИС: графическом отображении бизнес-процессов, форматах структур данных, отчётах ИС, ролях пользователей, печатных формах. Таким образом, на этом этапе закладываются основы документарной поддержки СУ.
Учёт фактических данных в той или иной форме ведётся в компании всегда. А вот возможность полноценного решения четвёртой задачи ИС – планирования и прогнозирования, появляется только с момента внедрения ИС.
Планирование, как система целеполагания, является неотъемлемой частью системы управления компанией. В ходе работ над проектом ИС определяются состав планов, горизонты и периоды планирования, бизнес-процесс и средства ввода плановых значений, форматы план-фактных отчётов, бизнес-процессы план-фактного анализа и коррекции планов. Перечень планируемых показателей определяется списком, сформированным в ходе реализации методики Balanced Scorecard. Особого внимания заслуживает система бюджетирования, которая является основой системы управления финансами. На этапе управленческого консалтинга внедрения ИС разрабатывается регламент бюджетирования, который включает в себя
- Описание финансовой структуры
- Форматы бюджетов
- Учётную политику
- Бизнес-процессы и правила их исполнения
Если планирование – это способ постановки целей, то прогнозирование – это формирование наиболее вероятного развития событий на основе ранее собранной объективной информации. Современные ИС предоставляют широкие возможности для финансового прогнозирования, предназначенного для своевременного принятия эффективных решений в области оперативного управления финансами. В некоторых ИС реализован механизм номенклатурного прогнозирования сбыта в натуральных единицах, что позволяет оптимизировать складские запасы и логистические ресурсы. На этапе управленческого консалтинга определяется состав прогнозов, которые будут использоваться менеджерами предприятия, их настойки, бизнес-процессы и регламенты применения. Таким образом, возможности ИС по прогнозированию интегрируются в СУ.
Интеграция ИС и СУ на процедурном уровне обеспечивается на этапе управленческого консалтинга путём разработки, оптимизации и согласования бизнес-процессов. В нашем списке задач ИС, поддержка бизнес-процессов фигурирует под последним номером. Это место определяется логикой разработки проекта ИС, поскольку в бизнес-процессах на процедурном уровне фиксируются все ранее принятые решения по организации управления по показателям, учёту, документообороту, планированию и прогнозированию.
Бизнес-процессы разрабатываются в тесной связи с другими документами организационного дизайна компанией. Например, права участников бизнес-процессов должны быть согласованы со структурой управления, а выполняемые функции – с должностными инструкциями. Ряд бизнес-процессов требует дополнения регламентами, то есть документами, определяющими дополнительные условия исполнения бизнес-процессов. Фактически, при разработке этой части проекта ИС, формируется весь пакет организационных документов компании или проводится ревизия существующего оргдизайна.
Оптимизация бизнес-процессов – это отдельная серьёзная задача, требующая большого опыта и квалификации. Предложения по косметическому улучшению бизнес-процедур возникают уже на первом шаге при формализации и согласовании бизнес-процессов «как есть». Более глубокая оптимизация может быть предложена на основе анализа стратегии и тактики компании, который проводится в ходе первого этапа управленческого консалтинга – диагностики системы управления. Разумеется, глубина реинжиниринга бизнес-процессов определяется руководством компании.
До определённого уровня детализации описание бизнес-процессов не зависит от ИС. Однако, при внедрении ИС полезно детализировать бизнес-процессы до документов ИС, что позволяет в дальнейшем использовать их, в качестве инструкций операторов, а также для формирования сценариев обучения пользователей.
Несколько слов о процедуре выполнения этапа управленческого консалтинга внедрения ИС. На рис. 1 представлена общая процедура проведения работ по управленческому консалтингу компании, а пунктиром выделены работы, относящиеся к этапу управленческого консалтинга внедрения ИС. Из самой процедуры видно, что на вход внедрения ИС должны быть переданы исходные данные, а именно, стратегия компании. Если стратегия в компании не сформулирована или проработана недостаточно подробно, внедрение ИС не приведёт к результату, удовлетворяющему руководство заказчика, так как будет основано на представлениях самих внедренцев и частных мнениях отдельных сотрудников компании-заказчика. Впрочем, отсутствие стратегии может привести компанию к ещё более печальным последствиям, чем неудачное внедрение ИС.
Процедура этапа управленческого консалтинга внедрения ИС начинается с диагностики системы управления, которая проводится в следующей последовательности:
1. Ознакомление с материалами компании
2. Совещание с руководителем компании, на котором уточняются
- направления деятельности компании (продукты, рынки сбыта)
- состояние системы управления
- список ведущих сотрудников, зоны ответственности
- существующие проблемы
- график интервью с ведущими сотрудниками компании
3. Интервью с ведущими сотрудниками
4. Согласование результатов интервью
5. Анализ существующих документов системы управления
6. Подготовка предложений по развитию системы управления
7. Подготовка предложений по плану работы
После согласования плана работы с заказчиком, разрабатывается проект ИС, в который входят следующие документы:
1. Условия использования ИС
2. Требования к функционалу, преемственности с действующим информационным обеспечением, информационной безопасности
3. Описание финансово-юридической структуры
4. Иерархия целей, система показателей
5. Форматы отчётов
6. Форматы печатных форм
7. Структуры данных
8. Описание ролей пользователей
9. Графическое отображение бизнес-процессов, подлежащих внедрению в КИС
10. Регламенты исполнения бизнес-процессов
11. Сценарии обучения пользователей
В процессе настоек ИС и доработок типового функционала консультант взаимодействует с внедренцами по вопросам формирования постановок задач и технических заданий, а в процессе обучения пользователей и запуска ИС в опытную эксплуатацию консультирует пользователей по вопросам, находящимся в его компетенции. Таким образом, работа консультанта начинается на самом раннем этапе внедрения и ИС и заканчивается только после перевода ИС в режим производственной эксплуатации.
Хочется надеяться, что в результате знакомства с этой статьёй потенциальные заказчики ИС согласятся с важностью и обязательностью этапа управленческого консалтинга внедрения ИС, а также будут лучше представлять себе состав и методику проведения работ этапа и получаемые результаты.
Рис. 1. Общая процедура Управленческого консалтинга
Я просто плакалЪ.Это что за бред рекламный?Афтор, вот такие вамподобные граждане лепят лапшу рекламную, топ-менеджерам, рисуют виртуальные схемки, не имеющие ничего общего с действительностью.А потом Ис и проваливаются на серьёзных предприятиях не паразитирующих, но производящих.Я специально осилил ваш скучный буклет и подумал насколько применим он к РЖД, к примеру.Ваша писанина на 70% не соответствует ни реальности ни её динамике развития предприятия.Вы наверное не имеете ни малейшего представления об реальных информационных системах и их работе и никогда не сталкивались с описанными вами этапами.Хотя предполагаю,что данный развод применим к предприятиям, которые могут позволить себе искать решения по оптимизации управления на Поле Чудес при отсутствии сложных бизнес-процессови весомой поризводственой составляющей.
Итак что мы имеем? Читаем статью; автор заявляет:« В статье описана методика формирования проекта ИС, обеспечивающая реализацию главного предназначения информационной системы – быть инструментом системы управления компанией.» Итак, в статье описана методика формирования информационной системы. Запомним это, чтобы не забыть, зачем пришли .Автор пишет : “Одна из главных причин неудачных внедрений – это слабая проработка проекта ИС на этапе управленческого консалтинга.” Автором устанавливается зависимость правильности, к примеру, архитектуры проекта от того, что там расскажут в консалтинговой конторе. То есть иными словами автор заявляет, что для начала нужно посоветоваться иначе проект может рухнуть. Он, конечно, может и не рухнуть, но одна из причин … и далее по тексту. Иными словами, автор ставит конкретную конечную потребность, допустим оптимизацию документооборота во главе архитектуры системы.Автор заявляет это и продолжает пламенную речь:«В результате ИС оказывается в недостаточной степени интегрирована в общую систему управления компанией (СУ), оставаясь, в лучшем случае дорогостоящим калькулятором для ведения управленческого и регламентированного учёта».Здесь мы видим изначально ущербную постановку проблемы. Автор предполагает, что на предприятии используется несколько информационных систем, интеграция между которыми составляет проблему. Безусловно, на большинстве предприятий реальность как раз таковой и является, и имеется множество мелких и не очень систем, которые друг с другом общаются зачастую посредством глухого телефона. Но автор, являющийся регаленосцем, должен был хотя бы упомянуть о том, что это есть неправильное решение, от которого большинство уважающих себя компаний на западе отказались. Он должен был хотя бы предположить, что у нас могут быть предприятия, предполагающие, что информационная система должна быть единой. Он должен был хотя бы предположить, что решение задачи расширения функционала может быть лишь расширением существующей архитектуры ИС. Данный подход создания единых информационных систем давно и успешно применяется на западе, но автор, настойчиво тянет нас в прошлое 90-х. Таким образом существует риск пролонгации теории разделения производственных показателей от тех же показателей эффективности отдельного сотрудника и подразделения. Другими словами количество произведённых деталей будет храниться в одной системе, а характеристики задач подразделения производящих детали будет храниться в другой системе. Это мало приемлемо для эффективного управления производством.Читаем далее:“Нужно сразу оговориться, что полный проект ИС включает в себя ряд вопросов, находящихся за рамками компетенции управленческого консультанта. В статье речь пойдёт о методике разработки тех документов проекта, которые формируются на этапе управленческого консалтинга, а под «проектом ИС» подразумевается совокупность этих документов”. Безусловно, автор прав. Нужно только заметить, что нормальная ИС, включающая в себя аналитику производственного процесса может находиться вне компетенции управленческого консультанта на процентов 80.Читаем сказки дальше, автор говорит о том, что должна обеспечивать ИС:“В общем случае ИС должна обеспечивать решение следующих задач:1. Сбор первичных данных о деятельности компании и представление их в удобном для анализа виде”Теперь представим прожженного директора завода, начальника отделения железной дороги, компетентных и знающих досконально своё предприятие. Тут вдруг, откуда ни возьмись приходят к нему умные люди и говорят: Хотите первичные данные? Вот назовите мне домохозяйку, которая хочет первичные данные о том, как держать нож при чистке картошки…. Итак, автор ставит проблему:“В начале 2000-х годов автор работал в оптово-розничной компании, использовавшей систему учёта товарно-материальных ценностей собственной разработки. К тому моменту в системе насчитывалось более 700 отчётов, в которых рассчитывались несколько тысяч показателей. Поскольку практики описаний отчётов не было и разобраться в этом хаосе не представлялось возможным, каждый новый менеджер заказывал себе 10-15 новых отчётов, мобилизуя на эту работу программистов всеми доступными методами. Знакомая картина непозволительного расходования ресурсов?”В описанном примере видна некорректность архитектуры информационной системы, отсутствие эффективной масштабируемости и расширяемости. Что же видит в описанной ситуации автор? А он не видит в этом проблемы. Читаем:“Возникает вопрос: как на этапе проектирования составить необходимый и достаточный список показателей, которые затем будут представлены в отчётах ИС, предназначенных для принятия управленческих решений? Поскольку мы определились с тем, что ИС должна стать инструментом СУ, ответ на этот вопрос очевиден: в ИС должны, в первую очередь, рассчитываться показатели, которые используются в СУ для контроля деятельности предприятия, подразделений, сотрудников.”Автор просто говорит нам: давайте оставим принцип качества построения ИС в покое, но определим необходимые и достаточный список показателей предназначенных для принятия управленческих решений. Смотрим смысл слов необходимый и достаточный. В данном контексте, основываясь на аналогии с математическим смыслом достаточного и необходимого признаков, мы имеем проблему формирования точного списка показателей для контроля деятельности предприятия. Показатель принадлежит списку, если он является контролирующим деятельность предприятия, и наоборот, если он контролирует деятельность предприятия, то он входит в список. Подобный подход выдаёт дилетанта. Ибо на этапе проектирования системы невозможно определить данные показатели, актуальность которых меняется в течение времени в зависимости, к примеру, от экономической ситуации. К тому же жесткая завязка ИС на данные показатели вызовет проблемы архитектурного плана. Безусловно, от каких-то показателей необходимо отталкиваться, но нужно абстрагироваться от них и вводить общие решения, применимые для любого показателя. В таком случае не возникнет проблемы устаревания системы на момент сдачи проекта.Далее, рекламу пропустим.Далее автор говорит с учёным видом умными словами о том, что для того, чтобы, что то рассчитать, нужны данные для расчета:“Для решения задачи ИС, перечисленной в списке под номером 1, системы показателей недостаточно. Необходимо также предусмотреть сбор первичных данных, на основе которых эти показатели будут рассчитываться. ”.Далее автор идёт дальше и предлагает зафиксировать ответственность Он говорит так же, что нужно общаться с заказчиком, и если чего тыкать ему в зафиксированные пункты проекта. Он видимо представления не имеет о цикличности разработки и проектирования, о том, что нет успешных проектов, не прошедших множественных циклов от архитектора до тестировщика. Однако, это незнание автор закрывает довольно второстепенным и банально известным откровением из учебников по информатике для 1-го курса. Убеждаемся:“ Решения о том кто, когда, по какому событию, при каких условиях регистрирует эти данные в ИС, должны быть зафиксированы в документах проекта: ролях пользователей, бизнес-процессах, регламентах, требованиях к функционалу. Не является также излишней проработка форматов отчётов, в которых показатели будут представлены. Если этот вопрос будет отдан на откуп программисту, заказчик может быть неприятно удивлён результатом в тот момент, когда обязательства внедренцев по этому вопросу будут уже выполнены. Активное участие заказчика в определении форматов является залогом получения результата в действительно «удобном для анализа виде».”Безусловно, весьма занимательно смотреть на детский сад от именитых мужей и разоблачать некомпетентность, но не думаю, что это полезно для меня сейчас. Потому, если будет время на досуге и желание, то может и продолжу размышление об опусе паразитирующего явления под названием некомпетентный консалтинг.
Уважаемый Игорь Анатольевич!Спасибо Вам за внимание к моей статье и высказанные полезные, конструктивные замечания. Я надеюсь, что столь подробный разбор моего творения, не повредил бесперебойному функционированию РЖД Челябинской области. Постараюсь растиражировать Ваш глубокий анализ моей статьи как можно шире. Пусть все пользователи РЖД знают, за что именно они платят свои кровные уважаемому монополисту!
РЖД челябинской области не существует.Читайте газеты смотрите ТВ.Весьма полезно.
Кстати дешёвый и недостойный способ раккции.Уровень копеешных журналистов.Есть такое понятие, как марка.Вы её не держите.
Уважаемый Игорь Анатольевич! Не складывайте оружия! На этом сайте есть другая моя статья, на моём сайте - ещё 'опусы паразитирующего явления под названием некомпетентный консалтинг'. Буду с нетерпением ждать Ваших новых откровений!
Я просто плакалЪ.
Это что за бред рекламный?
Афтор, вот такие вамподобные граждане лепят лапшу рекламную, топ-менеджерам, рисуют виртуальные схемки, не имеющие ничего общего с действительностью.
А потом Ис и проваливаются на серьёзных предприятиях не паразитирующих, но производящих.
Я специально осилил ваш скучный буклет и подумал насколько применим он к РЖД, к примеру.
Ваша писанина на 70% не соответствует ни реальности ни её динамике развития предприятия.
Вы наверное не имеете ни малейшего представления об реальных информационных системах
и их работе и никогда не сталкивались с описанными вами этапами.
Хотя предполагаю,что данный развод применим к предприятиям, которые могут позволить себе
искать решения по оптимизации управления на Поле Чудес при отсутствии сложных бизнес-процессов
и весомой поризводственой составляющей.
Итак что мы имеем? Читаем статью; автор заявляет:
« В статье описана методика формирования проекта ИС, обеспечивающая реализацию главного предназначения информационной системы – быть инструментом системы управления компанией.»
Итак, в статье описана методика формирования информационной системы. Запомним это, чтобы не забыть, зачем пришли .
Автор пишет : “Одна из главных причин неудачных внедрений – это слабая проработка проекта ИС на этапе управленческого консалтинга.” Автором устанавливается зависимость правильности, к примеру, архитектуры проекта от того, что там расскажут в консалтинговой конторе. То есть иными словами автор заявляет, что для начала нужно посоветоваться иначе проект может рухнуть. Он, конечно, может и не рухнуть, но одна из причин … и далее по тексту. Иными словами, автор ставит конкретную конечную потребность, допустим оптимизацию документооборота во главе архитектуры системы.
Автор заявляет это и продолжает пламенную речь:
«В результате ИС оказывается в недостаточной степени интегрирована в общую систему управления компанией (СУ), оставаясь, в лучшем случае дорогостоящим калькулятором для ведения управленческого и регламентированного учёта».
Здесь мы видим изначально ущербную постановку проблемы. Автор предполагает, что на предприятии используется несколько информационных систем, интеграция между которыми составляет проблему. Безусловно, на большинстве предприятий реальность как раз таковой и является, и имеется множество мелких и не очень систем, которые друг с другом общаются зачастую посредством глухого телефона. Но автор, являющийся регаленосцем, должен был хотя бы упомянуть о том, что это есть неправильное решение, от которого большинство уважающих себя компаний на западе отказались. Он должен был хотя бы предположить, что у нас могут быть предприятия, предполагающие, что информационная система должна быть единой. Он должен был хотя бы предположить, что решение задачи расширения функционала может быть лишь расширением существующей архитектуры ИС. Данный подход создания единых информационных систем давно и успешно применяется на западе, но автор, настойчиво тянет нас в прошлое 90-х. Таким образом существует риск пролонгации теории разделения производственных показателей от тех же показателей эффективности отдельного сотрудника и подразделения. Другими словами количество произведённых деталей будет храниться в одной системе, а характеристики задач подразделения производящих детали будет храниться в другой системе. Это мало приемлемо для эффективного управления производством.
Читаем далее:
“Нужно сразу оговориться, что полный проект ИС включает в себя ряд вопросов, находящихся за рамками компетенции управленческого консультанта. В статье речь пойдёт о методике разработки тех документов проекта, которые формируются на этапе управленческого консалтинга, а под «проектом ИС» подразумевается совокупность этих документов”. Безусловно, автор прав. Нужно только заметить, что нормальная ИС, включающая в себя аналитику производственного процесса может находиться вне компетенции управленческого консультанта на процентов 80.
Читаем сказки дальше, автор говорит о том, что должна обеспечивать ИС:
“В общем случае ИС должна обеспечивать решение следующих задач:
1. Сбор первичных данных о деятельности компании и представление их в удобном для анализа виде”
Теперь представим прожженного директора завода, начальника отделения железной дороги, компетентных и знающих досконально своё предприятие. Тут вдруг, откуда ни возьмись приходят к нему умные люди и говорят: Хотите первичные данные?
Вот назовите мне домохозяйку, которая хочет первичные данные о том, как держать нож при чистке картошки….
Итак, автор ставит проблему:
“В начале 2000-х годов автор работал в оптово-розничной компании, использовавшей систему учёта товарно-материальных ценностей собственной разработки. К тому моменту в системе насчитывалось более 700 отчётов, в которых рассчитывались несколько тысяч показателей. Поскольку практики описаний отчётов не было и разобраться в этом хаосе не представлялось возможным, каждый новый менеджер заказывал себе 10-15 новых отчётов, мобилизуя на эту работу программистов всеми доступными методами. Знакомая картина непозволительного расходования ресурсов?”
В описанном примере видна некорректность архитектуры информационной системы, отсутствие эффективной масштабируемости и расширяемости. Что же видит в описанной ситуации автор? А он не видит в этом проблемы. Читаем:
“Возникает вопрос: как на этапе проектирования составить необходимый и достаточный список показателей, которые затем будут представлены в отчётах ИС, предназначенных для принятия управленческих решений? Поскольку мы определились с тем, что ИС должна стать инструментом СУ, ответ на этот вопрос очевиден: в ИС должны, в первую очередь, рассчитываться показатели, которые используются в СУ для контроля деятельности предприятия, подразделений, сотрудников.”
Автор просто говорит нам: давайте оставим принцип качества построения ИС в покое, но определим необходимые и достаточный список показателей предназначенных для принятия управленческих решений. Смотрим смысл слов необходимый и достаточный. В данном контексте, основываясь на аналогии с математическим смыслом достаточного и необходимого признаков, мы имеем проблему формирования точного списка показателей для контроля деятельности предприятия. Показатель принадлежит списку, если он является контролирующим деятельность предприятия, и наоборот, если он контролирует деятельность предприятия, то он входит в список. Подобный подход выдаёт дилетанта. Ибо на этапе проектирования системы невозможно определить данные показатели, актуальность которых меняется в течение времени в зависимости, к примеру, от экономической ситуации. К тому же жесткая завязка ИС на данные показатели вызовет проблемы архитектурного плана. Безусловно, от каких-то показателей необходимо отталкиваться, но нужно абстрагироваться от них и вводить общие решения, применимые для любого показателя. В таком случае не возникнет проблемы устаревания системы на момент сдачи проекта.
Далее, рекламу пропустим.
Далее автор говорит с учёным видом умными словами о том, что для того, чтобы, что то рассчитать, нужны данные для расчета:
“Для решения задачи ИС, перечисленной в списке под номером 1, системы показателей недостаточно.
Необходимо также предусмотреть сбор первичных данных, на основе которых эти показатели будут рассчитываться. ”.
Далее автор идёт дальше и предлагает зафиксировать ответственность Он говорит так же, что нужно общаться с заказчиком, и если чего тыкать ему в зафиксированные пункты проекта. Он видимо представления не имеет о цикличности разработки и проектирования, о том, что нет успешных проектов, не прошедших множественных циклов от архитектора до тестировщика. Однако, это незнание автор закрывает довольно второстепенным и банально известным откровением из учебников по информатике для 1-го курса. Убеждаемся:
“ Решения о том кто, когда, по какому событию, при каких условиях регистрирует эти данные в ИС, должны быть зафиксированы в документах проекта: ролях пользователей, бизнес-процессах, регламентах, требованиях к функционалу. Не является также излишней проработка форматов отчётов, в которых показатели будут представлены. Если этот вопрос будет отдан на откуп программисту, заказчик может быть неприятно удивлён результатом в тот момент, когда обязательства внедренцев по этому вопросу будут уже выполнены. Активное участие заказчика в определении форматов является залогом получения результата в действительно «удобном для анализа виде».”
Безусловно, весьма занимательно смотреть на детский сад от именитых мужей и разоблачать некомпетентность, но не думаю, что это полезно для меня сейчас. Потому, если будет время на досуге и желание, то может и продолжу размышление об опусе паразитирующего явления под названием некомпетентный консалтинг.