Подходы к оценке эффективности решений по управлению архитектурой предприятия

55

При обсуждении архитектурной темы часто явно или неявно звучит вопрос «Как считать эффективность архитектурных инициатив (или использования архитектурного подхода как такового)?»

Эффективность всегда зависит от того, чего желаем достичь, а архитектура предприятия сама по себе является инструментом выяснения и оценки эффективности, а также оркестровки оценок эффективности для сложных социо-экономических систем с вовлечением множества различных интересов.

Что такое эффективность вообще? И в англоязычной, и в отечественной практиках термины — результативность и эффективность — часто используются как синонимы. В англоязычной практике (ISO 9000:2005) результативность — это сравнение факта результата с планом/целью — результат, взвешенный целью; эффективность — это оценка эффекта деятельности — результат, взвешенный совокупными затратами.

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

Это общее определение эффективности, охватывающее и результативность, и эффективность в терминологии ISO. Экономическая эффективность, определяемая как «результативность экономической деятельности, как отношение полученного экономического эффекта и затрат, обусловивших получение этого эффекта» (Экономика и право. Словарь-справочник, 2003), является лишь частным случаем ранее данного определения.

То есть, оценка эффективности предполагает формулировку цели (требуемого результата). Для систем уровня предприятия существуют различные интересы (участвующих в предприятии заинтересованных групп — стейкхолдеров), разные взгляды на предназначение, развитие предприятия и его подсистем, разные цели, а, следовательно, и разные эффективности.

Для примера, приведём некоторые категории интересов, целей и подходов к измерению эффективности, касательно ИТ и архитектурных работ (табл. 1-3).

Таблица 1

Интересы

Уровень

Учреждение архитектурной функциональности на предприятии

Инициативы в рамках архитектурных работ

Бизнес

Контроль над бизнесом. Получение эффективного инструмента по управлению бизнесом и его развитию.

Получение экономических результатов, добавленной стоимости. Рост бизнес-возможностей. Успешная бизнес-деятельность. Предоставление эффективного экономического-инструмента.

ИТ

Контроль над ИТ. Соответствие требованиям бизнеса. Успешное управление ИТ и их развитие.

Предоставление эффективного технологического инструмента в соответствии с потребностями бизнеса. Успешное удовлетворение потребностей бизнеса в сфере ИТ.

Проектный/функциональный уровень

Успешная операционная деятельность в архитектурной сфере.

Успешная проектная деятельность.

Таблица 2

Категории целей

Уровень

Учреждение архитектурной функциональности на предприятии

Инициативы в рамках архитектурных работ

Бизнес

Улучшение управляемости предприятия. Повышение качества управления бизнес-активами.

Реализация стратегических целей.

ИТ

Улучшение управления ИТ. Повышение качества управления ИТ-активами.

Обеспечение качества ИТ-сервисов.

Проектный/функциональный уровень

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

Должное выполнение проектных работ.

Таблица 3

Подходы к оценке эффективности

Уровень

Учреждение архитектурной функциональности на предприятии

Инициативы в рамках архитектурных работ

Бизнес

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

Показатели: KPI, инвестиционные показатели.

Экономическая эффективность (эффективность инвестиций в бизнес-функции, инструменты для бизнеса).

Показатели: Добавленная стоимость, ROI, инвестиционные показатели.

ИТ

Эффективность управления ИТ (эффективность ИТ-функции/работы ИТ-служб).

Показатели: отзывчивость на потребности бизнеса, KPI.

Эффективность ИТ-решений, средств и инструментов (эффективность создаваемых инструментов/систем).

Показатели: соответствие поддерживаемым бизнес-функциям/процессам, качественные характеристики систем.

Проектный/функциональный уровень

Операционная эффективность (эффективность выполнения функции/операции).

Показатели: качество выполнения работ, зрелость, KPI.

Проектная эффективность (эффективность реализации проектов).

Показатели: сроки, расходы, качество, др. проектные показатели.

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

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

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


11180
Коментарии: 55

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    15.06.2013 16:57

    Чем выше уровень, тем выше неопределённость, тем сложнее оценка. На нижних уровнях возможно использование стандартных формальных показателей - конечно. Но вопрос разработки показателей нижнего уровня - уже проект, затраты ресурсов. Получается, что для того чтобы оценить эффект - надо затратить денег (а эот надо тоже обосновать), и круг замыкается. Есть какой-то практический опыт, когда "с нуля" или в ходе предпроектных (пресейловых) работ удается рассчитать эффективность подобного проекта и обосновать заказчику, что в проект стоит вкладывать деньги?

    • Дмитрий Капинос Михаил
      Рейтинг: 291
      МГУ, Экономический факультет
      Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
      18.06.2013 14:52

      Добрый день! Расчёт оценок эффективности на нижнем уровне -- это практически всегда чисто техническая и не слишком трудоёмкая задача с предсказуемыми трудозатратами. Выполняется штатными сотрудниками (непосредственно исполнителями), и по сравнению с ожидаемой на верхних уровнях отдачей эти затраты исчезающе малы (если, конечно, речь не идёт о космических проектах, да и то). Часто больше тратится на вынужденный простой персонала на регулярной основе, чем потребуется на расчёты. Так что никакого замкнутого круга нет. Есть обычная экономика с неизбежными текущими издержками и расходами (они есть и будут по-любому, даже если вообще ничего не делать, главное, чтобы эффект был больше). Оценки на верхних уровнях сложнее. Но для этого на тех уровнях трудятся специально обученные люди, которым за это зарплату, а иногда и бонусы, платят. Схематически, должно быть так: стратегические цели --> бизнес-цели --> ИТ-цели --> проектные/операционные цели. 1. Приходит бизнес-аналитик (или гений предпринимательства, в зависимости от обстоятельств) со стратегическим анализом и говорит: есть такие-то и такие-то возможности, если сделаем то-то и то-то в течение данного срока, при условии удержания не менее 50 % рынка, увеличим капитал в N раз. Вот обоснование: наш аналитический отдел, прогнозы Гартнер, аналитика BCG и т.д. Ожидаемая отдача: 10^9. (Допустим, они решили осуществлять розничные продажи и доставку группы товаров X в регионе M, заимствовав бизнес-модель из более развитых регионов. Канал сбыта -- Интернет; прямые поставки со складов, минус содержание магазинов и торговых точек, за счёт этого снижение цены. Скорость, удобство и цена -- конкурентные преимущества.) Цель, напр.: не менее 50 % доля в данном сегменте в течение 5 лет; или увеличение капитала в 5 раз. 2. Экономистам, инновационным менеджерам и проч. ставится задача: как это осуществить? Они думают и предлагают варианты, выбирают оптимальный. Обосновывают. Напр.: Нужно создать такие-то материальные, стоимостные, информационные потоки с такими-то параметрами. Цена вопроса: 10^8. Реализация невозможна без дистанционного канала продаж: Инет-ИС с такими-то возможностями/функциональностью. Цель, напр.: удвоение оборота каждый год по сравнению с предыдущим (темп прироста 100 %). 3. ИТ менеджерам ставится задача: дай ИС с такими-то характеристиками. ИТ думают, предлагают варианты, обосновывают выбор. Цена вопроса: 10^7. Цель, напр.: интернет-портал/магазин с заданными характеристиками. 4. Ну и проектные/операционные задачи -- понятно. Разбивка общей задачи на работы. Оценка ресурсов, сроков, затрат, рисков и проч. Если финансирование кредитное, то всё это ещё раз проверяется аналитиками кредитной организации. В том числе и запас прочности. Имеем: экономический результат = 10^9; расходы: создание экономического инструмента = 10^8, создание ИТ-инструмента = 10^7; прочие расходы (допустим) = 10^6. Выполняем прогнозные оценки показателей эффективности. Напр.: ROI, NPV и проч. инвестиционные показатели, проектные показатели (время, бюджеты и т.д.) и т.п. Факт потом сравниваем с этими прогнозами. Самое сложное здесь -- это оценка отдачи/цены на верхних уровнях. Чем выше уровень, тем больше факторов будут влиять на результат, тем всё более и более то, что мы ожидаем, вилами на воде писано. И здесь многое будет зависеть от качества человеческого материала: инсайтов, опыта/набитых шишек, интуиции, креативности и т.д. (иначе все бы уже давно были успешными предпринимателями). Сами по себе показатели эффективности -- это математика (более или менее сложная, но всегда шаблон и алгоритм). Я думаю это правильный подход к оценке эффективности. Конечно, инициатива может возникнуть на любом из уровней, но тогда тем, кто выходит с инициативой нужно: а) как минимум, представлять себе цели стейкхолдеров вышестоящих уровней; б) как максимум, взять на себя все необходимые оценки вышестоящих уровней (функции всех вышестоящих аналитических служб). Ну и, соотв., в случ. (б), обладать всеми необходимыми компетенциями, информацией и статусами/правами. Что, в принципе, возможно, но проблематично (как показывает практика различных Кулибиных). А если же всё происходит снизу вверх, вроде: ИТ приходит к бизнесу и просит денег на интересную/модную штуку "как у других", бизнес даёт из бюджета на "потратить и забыть", а потом чешет репу, как бы это применить и что сказать собственникам/стратегам, то это в корне неправильно, я считаю. Хотя и знакомо, наверно.

      • Михаил Петров Дмитрий
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        18.06.2013 17:43

        Да, в теории - все логично. Я же про практику :)

        • Дмитрий Капинос Михаил
          Рейтинг: 291
          МГУ, Экономический факультет
          Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
          19.06.2013 23:24

          Ну так это ж не сферический конь в вакууме ) Ну, совсем чуть-чуть сферический, разве что )

          • Михаил Петров Дмитрий
            Рейтинг: 809
            Счетная палата Российской Федерации
            Директор департамента цифровой трансформации
            20.06.2013 15:28

            Как говорили классики - "теория без практики мертва" :)

            • Дмитрий Капинос Михаил
              Рейтинг: 291
              МГУ, Экономический факультет
              Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
              02.07.2013 11:53

              С классиками, конечно, не поспоришь. ) Однако, мы же ведём речь не о "теории без практики", а, как раз, о теоретическом обобщении практики. Теория без практики -- ненаучна, практика без теории -- называется "грабли".

              • Михаил Петров Дмитрий
                Рейтинг: 809
                Счетная палата Российской Федерации
                Директор департамента цифровой трансформации
                02.07.2013 19:50

                Конечно. В то же время - "обходя разложенные грабли, вы теряете драгоценный опыт" :)

                • Дмитрий Капинос Михаил
                  Рейтинг: 291
                  МГУ, Экономический факультет
                  Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
                  04.07.2013 13:39

                  : ) На этот счёт есть две противоречащие друг другу пословице-поговорки: "Умные учатся на чужих ошибках (граблях), дураки -- на своих" и "Кто несчастья (граблей) не видел, счастья не поймёт". Я думаю, что граблей по возможности лучше избегать. Но и негативный опыт -- это бесценно во многих случаях. Потому, что видеть со стороны -- это одно, а прочувствовать самому -- это другое. Как говорят американцы по тому же поводу: "Чтобы получить (сладкий) лимонад, надо чтобы сначала был (кислый) лимон". Смысл в том, что многие прорывные открытия появились только после того, как те или иные деятели столкнулись с проблемой, которая их больно ударила по лбу.

                  • Михаил Петров Дмитрий
                    Рейтинг: 809
                    Счетная палата Российской Федерации
                    Директор департамента цифровой трансформации
                    04.07.2013 22:31

                    Да, полностью согласен.

                • Дмитрий Капинос Михаил
                  Рейтинг: 291
                  МГУ, Экономический факультет
                  Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
                  04.07.2013 13:53

                  ЗЫ: и, кстати, реальные или типичные ситуации из практики (кейсы) всегда интересуют самого. Особенно если даётся вводная и предлагается ответить, как бы вы поступили в этой ситуации. А потом предлагается сверить с реальным или эталонным решением. Говоря же про грабли, кейсы с негативным опытом и борьбой с ним, вообще читаются как детектив. На память приходит кейс героической высадки японцев на астероид. На этом, вообще, вся художественная литература построена. Читать про то, как у других всё ровно и безмятежно никому не интересно. Сознание хочет конфликта, вызова, чтобы поболеть, попереживать и намотать себе на ус. Художественные книги, таким образом, тоже своего рода кейсы. Только сконструированные. Я вот думаю, не стартануть ли новое направление в литературе: захватывающие и поучительные истории из жизни управления и ИТ. Интересы, страсти, интриги, KPI и проч. -- определённо должно иметь успех. Жалко только, что блондинок в ИТ не оч. много...

                  • Михаил Петров Дмитрий
                    Рейтинг: 809
                    Счетная палата Российской Федерации
                    Директор департамента цифровой трансформации
                    04.07.2013 22:32

                    Жалко только, что блондинок в ИТ не оч. много...
                    Они маскируются под брюнеток :)

                    • Дмитрий Капинос Михаил
                      Рейтинг: 291
                      МГУ, Экономический факультет
                      Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
                      15.07.2013 17:02

                      Брюнеток мы тоже любим )

    • Дмитрий Капинос Михаил
      Рейтинг: 291
      МГУ, Экономический факультет
      Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
      18.06.2013 15:10

      Что касается практического опыта. С нуля -- это создание и развитие предприятия. Это предпринимательский опыт. У меня он, допустим, есть, но ничего такого, чем бы можно было сейчас похвастаться. Но я учусь, расту и ещё не вечер. ) В этом деле хочешь/не хочешь, а будешь просчитывать всё до мелочей, "с нуля", т.к. рискуешь своими собственными активами. Что же касается компании, где я сейчас работаю, то к нам, как правило, обращаются на той стадии, когда верхние уровни более-менее определились, чего хотят и идентифицировали проблему, которую им надо решить. Цена проблемы им +/- (а иногда и точно) известна, допустимая цена решения -- тоже. Если что, мы можем уточнить, ознакомившись с их идеями/обоснованиями. Они приходят и покупают у нас (или у кого-то ещё) решение. Эффективность этого решения мы, конечно обосновываем (что именно и зачем реализуем, что это даст в плане проблемы, сколько будет стоить, проектные характеристики). Если интересно, могу могу найти пару кейсов из нашей практики. Правда чуть позже, если позволите. Я сейчас в отпуске. )

      • Михаил Петров Дмитрий
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        18.06.2013 17:43

        Да, кейсы всегда на порядок интереснее! Буду очень благодарен. Хорошего отдыха!

        • Дмитрий Капинос Михаил
          Рейтинг: 291
          МГУ, Экономический факультет
          Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
          19.06.2013 23:26

          Спасибо! Как вернусь на рабочее место, подыщу что-нибудь поддающееся (моему) пониманию. )

          • Михаил Петров Дмитрий
            Рейтинг: 809
            Счетная палата Российской Федерации
            Директор департамента цифровой трансформации
            20.06.2013 15:31

            Ждем. Вы это - бросьте работать на отдыхе :) это неправильно.

            • Дмитрий Капинос Михаил
              Рейтинг: 291
              МГУ, Экономический факультет
              Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
              02.07.2013 12:07

              Ха ) Отдых отдыху рознь... ) Потом, у меня в общении здесь, может быть, персональный интерес. Отчасти мне интересен ваш (участников) опыт, отчасти -- проверка моих собственных идей на прочность, конструктивная критика. С последующим патчем и апгрейдом. Работа, чаще, мешает уделять общению здесь достаточно внимания, чем помогает. А так, я по мере сил и часто в нерабочее время с удовольствием читаю обсуждения, которые здесь ведутся, и ссылки, которые дают просматриваю. Так что, за ссылки на интересные топики вообще благодарен.

              • Михаил Петров Дмитрий
                Рейтинг: 809
                Счетная палата Российской Федерации
                Директор департамента цифровой трансформации
                02.07.2013 19:51

                Да, я тоже не удерживался - из отпуска сюда ходил :)

                • Дмитрий Капинос Михаил
                  Рейтинг: 291
                  МГУ, Экономический факультет
                  Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
                  04.07.2013 14:01

                  Это, вот, кстати, натуральный показатель эффективности портала. )

        • Дмитрий Капинос Михаил
          Рейтинг: 291
          МГУ, Экономический факультет
          Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
          02.07.2013 12:49

          Вот, Михаил Викторович, Вам мини-кейс на основе реального проекта (название и некоторые реквизиты компании убрал, чтобы не заниматься согласованиями и т.д.). В принципе, аналогичный мини-кейс можно накидать по др. отраслям и неархитектурным работам, не особо специфично. Но, поскольку, как я понял из нижесказанного, Вы ждёте детальных данных (которых у меня нет), думаю в повторении нет особого смысла. КЕЙС Архитектурные работы в крупной продуктовой розничной сети Крупная компания, на рынке продуктов питания более 10 лет. Имеет собственные складские мощности на нескольких территориально-удаленных площадках, сеть розничных магазинов. Осуществляет оптовые продажи. Основные поставщики – непосредственно производители продукции. Доставка товаров осуществляется собственным и частично арендуемым автомобильным транспортом, а доставка грузов от поставщиков организуется преимущественно железнодорожным транспортом. Проблема Компания интенсивно росла и вместе с этим возросло число некорректных поставок, объема рекламаций, усложнилась работа с клиентской базой. Причина: существующая организация работ достигла своего предела, используемые регламенты и технологии уже не позволяли успешно обрабатывать непрерывно-возрастающий товаропоток. Собственник принял решение о реорганизации. Первый шаг — приглашение команды опытных менеджеров, которые заняли большинство руководящих позиций. По их мнению, одним из факторов ограничивающих развитие, являлись используемые на предприятии ИТ: морально устарели технологически, перестали соответствовать изменяющемуся стилю работы компании, нет чёткого понимания их организации (наследовались, проблема контроля). Решение Цена вопроса: устранение существующих негативных моментов (простои мощностей, неэффективное управление товаропотоками, возвраты и проч.) и ожидаемые эффекты развития (возможности дальнейшего расширения, без паралича бизнеса и др.). Менеджмент решил не изобретать велосипед, внедрить корпоративную информационную систему (КИС) и привлечь проектную команду для решения этой проблемы. Перед командой были поставлены следующие задачи: - Определить границы проекта (подразделения, бизнес-процессы, охватываемые КИС, ограничения и риски внедрения, очередность и др.). - Сформулировать требования к целевому состоянию бизнес-процессов, подлежащих автоматизации. - Разработать требования к КИС. - Произвести выбор КИС, которая бы удовлетворяла утвержденным требованиям и ограничениям на внедрение. Проектные работы Специалистами группы РДТЕХ были выполнены следующие работы. Определены ключевые сотрудники заказчика. На основе проведённых с ними встреч по обсуждению текущей бизнес-практики были зафиксированы их ожидания от внедрения КИС и требования к средствам автоматизации. Сформирована рабочая группа, в которую вошли сотрудники Заказчика и РДТЕХ. Группа построила «дерево» бизнес-целей (декомпозиция целей, формулируемых собственниками, на более низких уровнях организационной иерархии), определила их приоритеты. В ходе обсуждений и переговоров были сняты неизбежные разногласия, возникающие у топ-менеджеров и иных стейкхолдеров в процессе обсуждения возможных путей развития компании. Параллельно велось описание текущих бизнес-процессов («как есть»), выявлялись недостатки, проблемы существующей бизнес-практики (часто неочевидные даже для «старожилов»). На основе сопоставления дерева целей (чего хотим?) и иерархии бизнес-процессов (какие средства используем?) был проведён gap-анализ на предмет адекватности хозяйственных процессов предприятия стоящим перед ним целям (с акцентом на автоматизации). На основе этого анализа определены мероприятия по приведению процессов в соответствие с целями. Взаимосвязанные или схожие мероприятия были объединены в блоки задач. Из них были отобраны наиболее приоритетные (в соотв. с определёнными ранее приоритетами целей). На их основе были очерчены области охвата работ, куда в частности вошли: организация закупок; пополнение запасов; управление запасами, виды запасов; ценообразование; сбытовая логистика; планирование входящего и исходящего транспорта и др. Далее, по каждому из блоков задач были выполнены следующие работы. Для каждого из бизнес-процессов, на которые оказывают влияние задачи из рассматриваемого блока, было определено его целевое состояние. Для этого были описаны основные шаги каждого процесса и его основные характеристики: время выполнения, ответственные, необходимая информация и результаты выполнения процесса, взаимодействие со смежными процессами. Специалистами компании РДТЕХ на основании требований к бизнес-процессам и описания существующих бизнес-процессов был разработан структурированный перечень требований к функциям КИС. В виде документа MS Excel, 50 разделов и около 450 пунктов, описывающих функции, которые должны присутствовать в КИС. Полученный список требований к КИС был предоставлен для рассмотрения и обсуждения представителям 18 компаний разработчиков и внедренцев, продвигающих на российском рынке готовые решения соответствующего класса. По результатам получилось, что рассматриваемые системы соответствовали предъявленным требованиям с полнотой от 30 % до 89 %. Каждым из поставщиков был представлен проект или альтернативные предложения по организации работ с определением их стоимости, состава и результатов. На этом этапе проекта список рассматриваемых систем был сокращен до пяти. Были организованы презентации каждой из пяти систем. Специалисты РДТЕХ определили требования к ходу презентаций и к представляемым материалам (с целью упростить и формализовать сравнение). После проведенных встреч специалисты Заказчика выбрали одну компанию для дальнейшего сотрудничества. Полученные результаты позволили уверенно и с полным пониманием приступить к работам по внедрению КИС и способствовали эффективному взаимодействию со специалистами по внедрению (специалисты и менеджмент Заказчика знали точно чего хотят и что и зачем ожидают получить). На уровне проекта: стандартные проектные показатели эффективности/результативности — сроки, расходы, использование ресурсов, качество работ. В общей картине (на более высоком уровне): достижение поставленных стратегических целей за счёт данных инвестиций в ИТ (все расходы на проект заведомо меньшие отдачи от решения вопроса) и оценка инвестиционной эффективности (в составе др. инвестиций в рамках данной программы, если они были).

          • Михаил Петров Дмитрий
            Рейтинг: 809
            Счетная палата Российской Федерации
            Директор департамента цифровой трансформации
            02.07.2013 21:16

            Спасибо большое за труд! Подход понятен. Да, Вы правы - хотелось бы более конкретных данных :) По выбору систем, кстати, я даже хочу дискуссию сделать... Ключевой вопрос. стандартные проектные показатели эффективности/результативности — сроки, расходы, использование ресурсов, качество работ - это стандартно для чисто ИТшной составляющей общего проекта по улучшению работы компании. А вот как это соотносится с устранение существующих негативных моментов (простои мощностей, неэффективное управление товаропотоками, возвраты и проч.) и ожидаемые эффекты развития (возможности дальнейшего расширения, без паралича бизнеса и др.). Менеджмент решил не изобретать велосипед, внедрить корпоративную информационную систему (КИС)? Почему именно КИС решает в данном случае проблемы? Были ли какие-то метрики именно у процессов? Как-то они сопоставлялись с целями и автоматизацией, т.е. как-то обосновывалось, что именно автоматизация (а не просто оптимизация процесса или "нанять еще одну девочку") улучшит эти метрики? Ну хоть какие-то примеры бы :) И далее еще один момент. С автоматизацией еще худо-бедно обычно понятно, можно что-то показать и доказать. А вот если мы говорим (возвращаясь к заголовку дискуссии) об архитектурном проекте в общем, где как результат - не обязательно именно автоматизация, тут как-то становится вообще все "туманно"... И еще. До какой глубины Вы доходили в as is? Не было ли проблемы - особенно в условиях, как я понимаю, бурной перестройки компании - что as is устаревало не успев быть всеми подписанным? что as is вообще давало в данном случае для проекта? Мы, кстати, в наших условиях перманентных перемен, как правило, as is практически не делали и шли по "на лету рождавшейся" agile методике - тут вот обсуждали плюсы и минусы такого подхода...

            • Дмитрий Капинос Михаил
              Рейтинг: 291
              МГУ, Экономический факультет
              Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
              04.07.2013 14:05

              По выбору систем, кстати, я даже хочу дискуссию сделать... С интересом бы почитал и в меру сил поучаствовал, если будет что добавить сказать. Выбор -- это близкая мне тема, входит в научные интересы. Когда начнёте тему, дайте здесь ссылку, если не затруднит.

              • Михаил Петров Дмитрий
                Рейтинг: 809
                Счетная палата Российской Федерации
                Директор департамента цифровой трансформации
                04.07.2013 22:33

                Конечно

            • Дмитрий Капинос Михаил
              Рейтинг: 291
              МГУ, Экономический факультет
              Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
              04.07.2013 15:28

              Как стандартные проектные показатели увязываются с бизнесовыми? Поскольку процесс изменений нисходящий, цели и задачи спускаются сверху, то и показатели эффективности логически взаимосвязаны. Результаты нижних уровней влияют на показатели верхних. Я ранее описывал эту схему. Сначала у топов возникло понимание, что есть проблема. По их требованию был проведён анализ и выявлено в чём конкретно проблемы: простои, неэффективные товаропотоки, возвраты и т.д. Или: в планах открытие новых магазинов в городе N, это приведёт к тому, что в существующей системе нагрузка на мощности возрастёт до 100+ %, получение данных для аналитики займёт +бесконечность, существующие транспортно-складские мощности не справятся с дополнительным товаропотоком и т.д. Далее по их же требованию осуществляется поиск решений, их обоснование и выбор оптимального варианта (где-то это делается с использованием формальных методик, где то волевое решение на основе интуиции или "я так вижу"). Здесь работают бизнес-аналитики, инновационные менеджеры, инвестиционные менеджеры, экономисты и т.п. Результат их усилий: инвестиционный проект, где написано, как, по их мнению и расчётам, выбранное решение, будучи воплощено, должно повлиять на выявленные проблемы, напр.: простои -- снижение на 60 %, эк. выгода X тыс. руб. (простая формула: сокращённое время простоя * повремённую цену использования актива; сложные расчёты: с учётом не только прямых но и косвенных эффектов); неэффективные товаропотоки -- повышение скорости доставки на ..., повышение плотности потока/пропускной способности на ..., и т.д. --> снижение простоев/расходов транспортных и складских мощностей; эк. выгода -- аналогично; возвраты -- возрастание выручки на ... и т.п.; эк. выгода: рост оборота (или более сложные расчёты). Или: Реализация выбранного решения позволит успешно открыть новые магазины в городе N, т.к. все перечисленные риски/ограничения (в существующей системе нагрузка на мощности возрастёт до 100+ %, получение данных для аналитики займёт +бесконечность, существующие транспортно-складские мощности не справятся с дополнительным товаропотоком и т.д.) будут сняты или смягчены до приемлемого уровня. Что в свою очередь выразится в конкретных экономических показателях (от проекта расширения бизнеса): рост капитала в N раз, рост нормы и/или массы прибыли и т.д., или каких-то нефинансовых стратегических показателях, типа доли рынка, при сохранении или временном ухудшении финансовых. Если в ситуации с простоями и т.п. эффект от решения улучшающий, то в плане развития решение просто является условием осуществимости: не будет это сделано с заданными показателями качества, ничего не получится (такая булева переменная -- всё или ничего). С плюсами мы определились, теперь надо посчитать инвестиции -- сколько денег, времени и усилий (всё пересчитывается в деньги умножением на цены ресурсов) на реализацию этого решения надо потратить. И стоит ли вообще шкурка выделки. Считаются инвестиционные показатели: NPV, IRR, ROI, срок окупаемости и др. по мере необходимости. Задаются требования/параметры проектов/KPI которые служат целями для конкретных исполнителей (в данном случае для нас). Те самые стандартные показатели. С ними Заказчик приходит к своим внутренним исполнителям, или к внешним (к кому пойти, это тоже вполне считается) и говорит: "надо так". "Нет, так не сможем". "Пойдём к другим". Или по-другому: "За сколько сделает". "За столько". Смотрит у себя в расчётах и видит, что исполнители совсем, извиняюсь, офигели, или, наоборот, видит, что согласны сделать за меньшую цену (время и проч., конвертируемое в цену) по сравнению с ожидаемой. В последнем случае Заказчик покупает услугу Исполнителя и ревностно следит за установленными показателями. Теперь обратный подсчёт эффективности по результатам. Допустим, отклонились по срокам (потому, что если отклонение по стоимости/трудозатратам, то это отклонение будет покрываться за счёт Исполнителя -- если он внешний). Задержка завершения проекта сдвигает во времени получение всех ожидаемых положительных эффектов на уровне бизнеса (все они по большему счёту могут быть монетизированы), а это влияет практически на все инвестиционные показатели: NPV уменьшится, ROI уменьшится, срок окупаемости возрастёт и т.д. Может быть ситуация, когда проект выполнен без замечаний, а ожидаемый эффект не совсем тот. Тогда вопрос к бизнес-аналитикам. Проверять расчёты, искать причину. Это симптом, что чего-то не учли. И лучше это выяснить, чтобы: а) исключить неожиданности; б) в след. раз учесть и сделать лучше. Что касается экономических обоснований выбора варианта решения в данном случае, то нам (по кр. мере мне) они неизвестны. Это территория топов. Нас привлекли на стадии, когда этот этап уже был закрыт и мы имели дело только с целями и требованиями. Никакой принципиальной разницы между КИС и ещё одной девочкой нет: рассматриваются все варианты и выбирается оптимальный по заданным критериям. Просто в данном случае невооруженным глазом видно, что проблемы с управление и оркестровкой деятельности, а не с объемом мощностей (кол-вом девочек, магазинов и т.д.). Более того, наращивание мощностей само стало обострять проблему.

              • Михаил Петров Дмитрий
                Рейтинг: 809
                Счетная палата Российской Федерации
                Директор департамента цифровой трансформации
                04.07.2013 22:36

                Да, все правильно! Но вот примерчик бы... одним глазком... кусочек экселя... :) Ну мозг у меня так устроен - когда вижу пример, тут же все как-то "приземляется" и делается на порядок нагляднее...

                • Дмитрий Капинос Михаил
                  Рейтинг: 291
                  МГУ, Экономический факультет
                  Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
                  15.07.2013 17:00

                  Боюсь, кусочком экселя в случае верхнеуровневых обоснований не обойдётся. ) Ну или что-нибудь типа альтинвеста, разве что.

                  • Михаил Петров Дмитрий
                    Рейтинг: 809
                    Счетная палата Российской Федерации
                    Директор департамента цифровой трансформации
                    15.07.2013 17:53

                    Мне кусочка хватит :)

            • Дмитрий Капинос Михаил
              Рейтинг: 291
              МГУ, Экономический факультет
              Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
              04.07.2013 17:00

              Оценка эффективности архитектурного проекта Принципиальной разницы нет. Всё то же самое. На бизнес уровне либо улучшающие эффекты, либо разрешающее решение. Улучшающие: это повышение качества управления, что бизнес, что ИТ, снятие рисков, конфликтов/сопротивления, упомянутого здесь ув. Федько броуновского движения (отсутствия направляющей, периодической смены курса из частных соображений) и т.д. Всё при желании пересчитывается в фин. показатели. Напр., если время на принятие управленческого решения с учётом всех согласований и предложений сокращается с 2 нед. до 2 дн., то разницу можно взвесить ценой времени участников. Аналогично если старт проекта сокращается с 2 мес. до 2 недель. И т.д. Про ситуацию "ИТ = чёрная дыра" и говорить нечего, тут можно от жертвоприношений и камлания перейти к эффективности. Разрешающее решение, это, напр., когда без внедрения архитектурной функциональности просто нельзя достичь многообещающих стратегических, бизнес и ИТ целей. Например, слияние/поглощение крупных сложных компаний. Для успешного осуществления необходимо хорошее понимание систем на всех уровнях, как сочетать, что оставить, от чего отказаться. В художественной форме эта ситуация отражена в занятном фильме Области тьмы (Limitless, 2011), там вершиной карьеры чудесным образом интеллектуально прокачавшегося персонажа стал как раз обсчёт такой сделки. Архитектура, это конечно не MZT, но ясности добавляет существенно (и ломки нет). Т.е. вы инвестируете в архитектурные работы и ожидаете отдачи от повышения качества/производительности в течении последующих лет. И неэффективность архитектурного проекта все эти ожидания ухудшает. Либо вы инвестируете в архитектурные работы и это позволяет вам достичь желанной стратегической/бизнес цели, неэффективность арх. проекта это достижение либо отдаляет, либо делает его невозможным. Всё по аналогии со сказанным ранее. Главное иметь цели и начинать именно с них. Архитектура не самоцель. Глубина детализации и необходимость "as is" Подробность описания и состав всегда определяется текущей задачей. Поскольку в данном случае речь шла о внедрении КИС, описание бизес-процессов выполнялось достаточно детально (чтобы можно было проследить движение материальных, информ. потоков, описать необходимые ресурсы, в т.ч. информационные, и сформулировать требования бизнеса), в то же время каких-то инфраструктурных вещей, архитектур данных (не информации) и приложений в данном случае подробно не касались. С "как есть" аналогично. Такое описание делают тогда, когда ещё только надо определиться либо с целевым состоянием, либо с переходом к нему. В данном проекте: а) анализировали и искали недостатки/узкие места/несоответствие целям/возможности для улучшений (т.к. нужно было улучшать, не прерывая деятельности компании и с учётом специфики, а не ломать и строить заново); б) формировали требования к целевому состоянию БП, а затем к КИС. Опять же, у стейкхолдера, для которого выполняется архитектурное описание, должна быть ясная картина откуда начали и куда двигаемся. Иначе ему может начать казаться, что ничего не происходит или раньше было правильно. И в данном случае, и вообще, бизнес-процессы не меняются постоянно (это, как правило, какие-то изменения-всплески и сами по себе согласования реорганизаций длятся заведомо дольше, чем требуется на описание), опять же, внести коррективы в уже описанный процесс особого труда не составит. Если сразу есть понимание "как должно быть", то нет особого смысла выполнять формальные "как есть". И вообще догматически следовать фреймворкам: они существуют, чтобы направлять, а не сковывать. Ваш топик по второй ссылке я читал. Там оч. интересные моменты есть в обсуждении. Напр., Хлопонин Л.А. рассказывает про то, как он фактически самостоятельно пришёл к архитектурной функциональности у себя на предприятии. Его схема вполне себе укладывается в TOGAF. Первую ссылку ещё не читал. Сейчас почитаю. )

              • Михаил Петров Дмитрий
                Рейтинг: 809
                Счетная палата Российской Федерации
                Директор департамента цифровой трансформации
                04.07.2013 22:52

                Всё при желании пересчитывается в фин. показатели. Напр., если время на принятие управленческого решения с учётом всех согласований и предложений сокращается с 2 нед. до 2 дн., то разницу можно взвесить ценой времени участников. Аналогично если старт проекта сокращается с 2 мес. до 2 недель.
                Вот именно тут и хочется пример! :) это ровно то, с какого вопроса мы практически начали - Есть какой-то практический опыт, когда "с нуля" или в ходе предпроектных (пресейловых) работ удается рассчитать эффективность подобного проекта и обосновать заказчику, что в проект стоит вкладывать деньги?. Просто навести все эти метрики и сказать (при чем не просто сказать - а ответственно сказать) что в результате проекта вот это и вот это будет улучшено на столько-то - это уже отдельный проект, усилия (а может быть и бюджет)...

                • Дмитрий Капинос Михаил
                  Рейтинг: 291
                  МГУ, Экономический факультет
                  Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
                  15.07.2013 16:54

                  Да, на уровне стратегическом или инвестиционном -- это полноценных отдельный проект, согласен. Часто с затейливой логикой и расчётами. Конкретный пример сразу привести затрудняюсь, т.к. у меня конкретно нет на руках достаточных данных, а сочинять не хочется. Но мысль составить кейсы-примеры с подробным описанием возможных расчётов на всех уровнях -- хорошая. Спасибо за идею! ) Поставил в стек на выполнение, буду подбирать материалы.

                  • Михаил Петров Дмитрий
                    Рейтинг: 809
                    Счетная палата Российской Федерации
                    Директор департамента цифровой трансформации
                    15.07.2013 17:52

                    Спасибо!

  • Виктор Федько
    Рейтинг: 367
    Независимый эксперт
    Эксперт
    15.06.2013 21:27

    .Опыт есть, хоть отбавляй :) Могу поделиться. Только по большей части все напоминает продажу "трубы от граммофона" (Помнишь "Начальник Чукотки" ?). Эффективность проекта рассчитать можно. Только вот когда проект выйдет на расчетную мощность, т.е. заработает полностью (а такого вообще не случается - есть у революции начало - нет у революции конца), выяснится, что затраты на проект как-то сами по себе случайно возросли (недавно об этом тут говорили), а потому отдача (ROI) отодвигается до лучших времен. Более того, во время внедрения проекта сменился CEO (или CFO, CTO etc ). А также CIO (реально не один). Потому сроки, цели и бюджеты сильно изменились. При этом кажый новый CIO изображает из себя , как правило, автомеханика в сервисе - какой дурак до меня копался в вашем моторе ? :) Далее все понятно. Для примера - знаю один металлургический комбинат, довольно крупный Внедрение западной ERP (самой ныне востребованной, уважаемой и распространенной ) там началось в 1998 году. Не знаю, закончили или нет, но лет 5 назад еще нет - точно. За это время сменилось 4 CIO. Каждый уходящий удивительным образом переезжал в Москву с покупкой новой квартиры. Ну и как тут насчет эффективности и результативности ? Но, кстати, комбинат работает и довольно успешно.

    • Дмитрий Капинос Виктор
      Рейтинг: 291
      МГУ, Экономический факультет
      Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
      18.06.2013 15:23

      О, Виктор Александрович, это прекрасная и хорошо узнаваемая иллюстрация! Сам хотел что-то такое изложить, да постеснялся. ) Собственно, это классика, по причине которой архитектурный подход и появился. Разберём кейс? )

      • Виктор Федько Дмитрий
        Рейтинг: 367
        Независимый эксперт
        Эксперт
        18.06.2013 15:26

        Отчего ж не разобрать то.)) Давайте попробуем.

        • Михаил Петров Виктор
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          18.06.2013 17:44

          Кейс в студию!

          • Виктор Федько Михаил
            Рейтинг: 367
            Независимый эксперт
            Эксперт
            18.06.2013 18:32

            Я бы сказал - в сайт его сюда)))

          • Дмитрий Капинос Михаил
            Рейтинг: 291
            МГУ, Экономический факультет
            Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
            19.06.2013 23:31

            Дык, уже ж в студии. ) Виктор Александрович, вот, нам изложил ситуацию (весьма типичную, на мой взгляд). Я предлагаю примерить на себя костюмы Пуаро и Холмса, разобрать ситуацию (кейс) и ответить на вопросы: Кто виноват (почему так случилось)? и Что (надо было) делать? Могу изложить своё видение. Если где ошибусь, поправите.

            • Михаил Петров Дмитрий
              Рейтинг: 809
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              20.06.2013 15:30

              Я под кейсом имел ввиду конкретный какой-нибудь пример с расчетами - типа "вот, перед проектом (начальные предпосылки - такие-то) думали так и обосновывали его вот так, хотели достичь такого-то эффекта (и его рассчитывали таким образом), получилось вот так, почему..." Очень люблю цифры и конкретику :)

              • Дмитрий Капинос Михаил
                Рейтинг: 291
                МГУ, Экономический факультет
                Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
                02.07.2013 12:31

                Ну, такую детализацию, по сути проектную документацию и решение с фактическими данными, вряд ли кто-нибудь даст. По ряду причин. Во-1х, менеджеры не дадут на всякий случай (а вдруг что-нибудь секретное узнают конкуренты, а вдруг расстроится заказчик и т.д.). Во-2х, полной информации зачастую ни у кого (кроме топов заказчика, разве что) на руках нет (в лучшем случае, заказчик сообщит нам о своих интересах и целях, в остальном мы можем только догадываться). В-3х, переформатировать проектную документацию/решения для форума -- зашьёшься: времязатратно и не имеет особого смысла (лучше, уж тогда её иным способом опубликовать, в виде диссертации, напр., я припоминаю такие, доступны в чит.зале РГБ -- много теории, много обоснований, много цифр в приложении теории к конкретному кейсу). В-4х, по тем данным, что есть, нет особого смысла расписывать расчёт стандартных показателей -- это есть в каждом учебнике; достаточно упоминания. По моему, кейсы как таковые или ситуативный анализ -- это немножко не о том. Они основаны на реальных ситуациях, но интересуют скорее общее видение ситуации, анализ причин/тенденций, выбор направлений действий (почему поступили так, какие были возможности, как бы можно/нужно было поступить -- "кто виноват + что делать", короче). Конкретные значения переменных туда вводятся часто лишь для того, чтобы замаскировать суть и проверить способность аналитика отсеивать лишнее. Хотя, бывают конечно ситуации, когда критически важна деталь (должна действовать на аналитика как стоп-сигнал), но это, как мне кажется, не наш случай.

                • Михаил Петров Дмитрий
                  Рейтинг: 809
                  Счетная палата Российской Федерации
                  Директор департамента цифровой трансформации
                  02.07.2013 19:55

                  Да, трудозатратное это дело - документы для всеобщего показа обезличивать :( Насчет учебников и стандартных вещей - ну не люблю я их, столько перечитано, а пока на примере не показано - нет ощущения реальности и соответственно доверия :)

                  • Дмитрий Капинос Михаил
                    Рейтинг: 291
                    МГУ, Экономический факультет
                    Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
                    04.07.2013 17:09

                    Тут дело ещё в том, что нет полноты данных. Чего-то не попадало к нам никогда (было и осталось у Заказчика), что-то имеется но не в полном объёме (сводки, не первичка и т.д.). Опять же, если есть методика/расчёты, чтобы публиковать надо: а) спросить разрешения у всех; б) проверять на адекватность и т.д. В общем, сложно. Вместо учебников тогда можно читать диссертации. Там практическая часть с расчётами обязательное требование. )

                    • Михаил Петров Дмитрий
                      Рейтинг: 809
                      Счетная палата Российской Федерации
                      Директор департамента цифровой трансформации
                      04.07.2013 22:53

                      А вот до диссертаций уже руки не доходят :( Хочется как-то полегче, побыстрее - с помощью коллег на этом сайте например ;)

  • Михаил Петров
    Рейтинг: 809
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    15.06.2013 21:42

    Пять баллов! PS. По факту - это каждый сможет оценить :)

    • Дмитрий Капинос Михаил
      Рейтинг: 291
      МГУ, Экономический факультет
      Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
      18.06.2013 15:32

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

      • Михаил Петров Дмитрий
        Рейтинг: 809
        Счетная палата Российской Федерации
        Директор департамента цифровой трансформации
        18.06.2013 17:45

        Да, все правильно - только слишком обще :) давайте, как выше говорили, на кейсах, хорошая идея.

  • Виктор Федько
    Рейтинг: 367
    Независимый эксперт
    Эксперт
    15.06.2013 22:44

    Важно уметь объяснить и доказать - какой будет эффект! И высший пилотаж - уметь объяснить, почему вышеозначенный эффект не был достигнут! :)

    • Дмитрий Капинос Виктор
      Рейтинг: 291
      МГУ, Экономический факультет
      Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
      18.06.2013 15:42

      Полностью согласен. Даже если и сказано с иронией. ) Важно уметь объяснить и доказать - какой будет эффект! Для "продавца" оно само собой. Для того, кто будет отвечать за результат -- вдвойне. Особенно если ты одновременно и заказчик и исполнитель в одном лице. Уже хотя бы для самого себя первейшие вопросы с которых всегда следует начинать: "Зачем я это должен делать и каковы мои ожидания/шансы?" И высший пилотаж - уметь объяснить, почему вышеозначенный эффект не был достигнут! :) Тоже обязательное требование, вообще. Если не можешь этого объяснить, значит ничего не контролируешь. Правильно? Или, если понимаешь, но не умеешь/стесняешься объяснить, будешь козлом отпущения. Никому от этого, на самом деле, -- ни несчастному, ни компании, -- профита в долгосрочной перспективе не будет. А вот если есть система уровня предприятия, облегчающая анализ причин успехов/провалов, то все от этого будут только в плюсе.

      • Виктор Федько Дмитрий
        Рейтинг: 367
        Независимый эксперт
        Эксперт
        18.06.2013 16:46

        Сказано это не с иронией. А с большим сарказмом :) А вот если есть система уровня предприятия, облегчающая анализ причин успехов/провалов, то все от этого будут только в плюсе. - вот я не уверен насчет плюса. Если есть успех - то чего анализировать. А вот попробуйте (только не в теории) сказать бизнесу, что помимо ИС нужна еще система анализа причин провалов внедрения той самой ИС - вот интересно. что Вам ответят :) Если ты одновременно и заказчик и исполнитель (то есть делаешь все своими силами) - то гораздо проще на самом деле. Сам придумал, сам реализуешь, самого и накажут, что плохо сделал (или наградят). Все в одном флаконе. А вот когда у тебя на поднайме исполнитель, все гораздо хуже. отвечать все равно придется, но еще и за косяки других. Хотя, по большому счету, они все равно твои - не тех нанял. Могу так говорить, поскольку сам был продавцом КИС и знаю, как это делается. потому и перестал им быть. Поймите меня правильно, но я с очень большим предубеждениям отношусь к фирмам-внедренцам, к консалтингу. (Был начальником отдела продаж консалтинга). И многие мантры знаю. И также знаю многое с "другой" стороны. Пока все идет хорошо, процесс движется, результат достигается (промежуточный), акты закрываются регулярно - полная всеобщая любовь. А как что-то пошло не так, начинаются "непонятки". Достается договор, изучаются пункты типа кто что был обязан и т.д и т.п.. то есть поиски виновных. А отвечает все равно CIO. Все равно он будет виноват. На самом деле красиво объяснить, почему не достигли результата - это самообман. Это просто красиво расписаться в собственном провале и сохранить хорошую мину при плохой игре. Вот почему и говорил это с сарказмом.

        • Михаил Петров Виктор
          Рейтинг: 809
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          18.06.2013 17:47

          ко всему вышесказанному хочется добавить только одно в части На самом деле красиво объяснить, почему не достигли результата - это самообман - зачастую не САМО-, а просто обман :)

          • Виктор Федько Михаил
            Рейтинг: 367
            Независимый эксперт
            Эксперт
            18.06.2013 18:29

            Абсолютно верно! В большинстве случаев именно это.

        • Дмитрий Капинос Виктор
          Рейтинг: 291
          МГУ, Экономический факультет
          Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
          20.06.2013 00:59

          Понятно. Вполне себе рациональная позиция. Я бы даже со многим согласился, но с некоторыми пунктами поспорю, не сочтите за схоластику. Больно бескомпромиссно, на мой взгляд. На счёт системы анализа провалов/успехов В цикле стратегического управления (да и всякого управления) один из неисключаемых шагов — контроль (анализ результатов). Это, банально, функция, обеспечивающая обратную связь после планирования и действия. Если на предприятии такой функции нет, всё — капец, считайте там нет менеджмента. Анализировать необходимо как провалы так и успехи, и то и другое делается не для того, чтобы кого-то наказать или оправдаться, а для улучшения будущей практики, самообучения на успехах/ошибках. Система такого анализа (не обязательно автоматизированная), по хорошему, должна уже быть до старта всякого иного проекта — ИС или не ИС. Да, когда полагаешься на субподрядчика риск для управленца возрастает. Но, что поделаешь, такова судьба менеджера. Согласен, нужно тщательнее подходить к подбору ресурсов. Или, как вариант, вместе с работой делегировать и ответственность. Поймите меня правильно, но я с очень большим предубеждениям отношусь к фирмам-внедренцам, к консалтингу. Ну, Вы в этом отношении не одиноки. ) Опять же, дыма без огня не бывает. Хотя консалтинг консалтингу рознь. Но меня вот что всегда в таких случаях интригует. Консультанты, интеграторы — это такой же трудовой ресурс, как и те, кто работает в ИТ по найму. Какой смысл его ругать? Во-1х, сам выбирал. Во-2х, рычагов заставить их исполнять обязательства достаточно. А отвечает все равно CIO. Все равно он будет виноват. Почему всё равно CIO и почему виноват? В срыве проекта может быть масса других причин, включая вполне себе объективные. Если есть система анализа, то проблема может быть замечена ещё на подходе и её может быть можно будет погасить в зародыше. А если нет — то да, поиск виноватого, когда всё пропало. На самом деле красиво объяснить, почему не достигли результата - это самообман. Это просто красиво расписаться в собственном провале и сохранить хорошую мину при плохой игре. Я с этим могу согласиться только отчасти. Во-1х, мы живём в мире, где КПД=100% невозможен в принципе. Поэтому даже без всякого обмана/самообмана должны быть фейлы. Просто потому, что "такова селяви" (кажется где-то здесь приводили красноречивую статистику результатов внедрения CRM?). И не все внедренческие проекты тривиальны по сути. Во-2х, понятно, что этим могут пользоваться в оппортунистических целях и банально обманывать. Но объяснить и обмануть — это разные вещи. И желательно, поэтому, чтобы имелась система (не только ИС, но и процедуры), позволяющая упростить объяснение (анализ) и затруднить, если не исключить, обман. Вот, что я понимаю под объяснением и под выгодой для всех. А если просто найдут (=назначат) виноватого и он сделает себе харакири, то никому пользы от этого не будет. Будет ещё одна профанация, только теперь уже на уровне управления. ЗЫ: сарказм — крайняя степень иронии, так что всё равно. )

  • Сергей Цветаев
    Рейтинг: 10
    ЗАО Лаборатория новых информационных технологий «ЛАНИТ»
    Руководитель проектов
    17.06.2013 17:35

    Эмерсон - 12 принципов эффективности:  первый принцип призывает к выработке четко сформулированных идеалов;  второй принцип - здравый смысл;  третий принцип - пользуйтесь услугами экспертного совета;  четвертый принцип - дисциплина;  пятый принцип - это честное ведение дела;  шестой принцип - ведение прямого, адекватного и постоянного учета;  седьмой принцип диспетчеризации;  восьмой принцип это стандарты и графики, которые иногда могут являться результатами точных математических расчетов, а иногда вообще могут не подаваться количественной оценке;  девятый принцип - стандартные условия;  десятый принцип составляет стандартизация операций;  согласно одиннадцатому принципу просто устных стандартных практических инструкций недостаточно, они должны быть зафиксированы в письменной форме;  двенадцатый принцип является вознаграждением за эффективный труд.

    • Дмитрий Капинос Сергей
      Рейтинг: 291
      МГУ, Экономический факультет
      Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
      18.06.2013 15:47

      Прекрасное! ) А откуда это (источник)? Перевод, как будто, немного неровный...

  • Сергей Цветаев
    Рейтинг: 10
    ЗАО Лаборатория новых информационных технологий «ЛАНИТ»
    Руководитель проектов
    17.06.2013 17:38

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

    • Дмитрий Капинос Сергей
      Рейтинг: 291
      МГУ, Экономический факультет
      Предприниматель, консультант в области управления и ИТ, к.э.н., преподаватель МГУ
      18.06.2013 16:01

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

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.