Управление архитектурой предприятия как способ «наведения мостов» с бизнесом

2 апреля 2013
268

Добрый день!

Меня зовут Илья Караваев, я работаю в компании РДТЕХ в должности руководителя практики ИТ-консалтинга.

В последнее время мы реализовали ряд проектов в такой интересной области, как Enterprise Architecture Management (EAM) и Business Process Management (BPM). Общая цель этих проектов — построение прозрачной и эффективной системы описания и управления изменениями в архитектуре предприятия под эгидой ИТ-служб.

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

Например, для целей управления архитектурой в одном из проектов был создан архитектурный репозиторий, содержащий описание:

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

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

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

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

В формате блога хотелось бы открыть обмен мнениями по поводу того, каким образом ИТ-архитекторам компаний удается находить общий язык с бизнесом и реально эффективные ИТ-решения. Я попытаюсь собрать опыт аналогичных проектов, выполненных нашими консультантами в различных компаниях и рассказать об используемых подходах.

Также в формате открытой дискуссии хочется обсудить различные вопросы:

 

  • Что такое ИТ-архитектура, архитектура предприятия и зачем этим нужно заниматься?
  • Какие, по мнению участников, стандарты, подходы и ПО управления архитектурой зарекомендовали себя с лучшей стороны? С чего нужно начинать построение архитектуры предприятия по-правильному?
  • Какие проблемы встречаются в работе архитекторов? Как найти общий язык с топ-менеджментом, подразделениями СМК, процессными офисами, бизнес-аналитиками и другими участниками управления архитектурой предприятия? Как правильно разграничить ответственность и построить общие процессы?
  • Как интегрировать методы описания и управления изменениями архитектуры предприятия с традиционными процессами управления ИТ?

 

Я надеюсь, что в ходе ведения этого блога и обсуждения вопросов откроются новые возможности для гибкого, адаптивного и по-настоящему эффективного стиля управления. Я уверен, что многие из методологических проблем управления архитектурой предприятия уже нашли своё решение в ходе проектов, и это будет полезно сообществу Global CIO.

17033
Поделиться
Коментарии: 268

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

  • Михаил Петров
    Рейтинг: 264
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    02.04.2013 23:46

    Илья, здравствуйте! Очень интересная тема на мой взгляд. Может быть, для затравки, Вы какое-то свое мнение изложите по предложенным Вами буллетам? Тем более что опыт у Вас есть...

  • Иван Чалей
    Рейтинг: 10
    ОАО "Сургутнефтегаз"
    Зам.нач-ка управления информационных технологий
    03.04.2013 12:09

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

  • Сергей Цветаев
    Рейтинг: 10
    1. Закрытое акционерное общество Лаборатория новых информационных технологий «ЛАНИТ»
    Руководитель проектов
    03.04.2013 14:19

    Илья, очень акктуально. Сейчас такое же решение пытаюсь выстроить для машиностроительного предприятия, т.к. разброс по ИТ системам от DOS до 1С. Согласен с Михаилом Викторовичем, выскажитесь по архитектуре, по влиянию отрасли на архитектуру, влияние команды ИТ на архитектуру и т.д.; естественно если все это есть

  • Дмитрий Капинос
    Рейтинг: 20
    МГУ, Экономический факультет
    Автор курсов, преподаватель
    04.04.2013 18:07

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

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

      Коллеги, давайте определимся сначала, что вкладывается в понятие ИТ-архитектура, архитектура предприятия - самый первый буллет. Телекоммуникационная схема? Размещение серверов? Системные решения (операционные системы, средства публикации сервисов и т.п.)? Функционал и взаимодействие бизнес-приложений (в наложении на бизнес-процессы)? Все указанное? + что-то еще? Для каждого из указанных компонентов последующие буллеты решаются по-разному. Очень много тут можно сказать, практически на диссертацию. Коллеги-топикстартеры, предложите костяк, опишите свой подход, пожалуйста :) тем более что у вас проекты есть на эту тему - есть откуда это взять как пример.

      • Дмитрий Капинос Михаил
        Рейтинг: 20
        МГУ, Экономический факультет
        Автор курсов, преподаватель
        05.04.2013 15:11

        Полностью с Вами согласен. Следует начать с основ и определиться с используемыми понятиями. Во-1х, чтобы избежать так называемого «птичьего языка» в общении с теми коллегами, кто ранее непосредственно архитектурными работами не занимался и не знаком с терминологией; во-2х, по причине уже указанной ниже – устоявшейся терминологии нет (особенно в русскоязычной среде), однозначные кальки с английского затруднены. Я бы мог, не претендуя на академичность, сделать по возможности краткий обзорный доклад по первому пункту списка «Что такое архитектура и её предназначение?» Михаил Викторович, как старожил форума (судя по рейтингу), подскажите, как это лучше сделать: разместить текст здесь или попытаться начать новую тему (как в последнем случае сохранить связность между обсуждениями, и потом вернуться к оставшимся пунктам исходного списка)? И ещё, есть ли здесь возможность публикации изображений? Заранее признателен за советы!

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

          Мое личное мнение - лучше здесь продолжить. Изображения (как и файлы) сейчас тут, как я понимаю, выкладывать некуда кроме как в разделы типа "Библиотека" через редакцию сайта. Это не особо оперативно. Можно скинуть на какую-нибудь файловую шару, а тут разместить ссылку.

          • Дмитрий Капинос Михаил
            Рейтинг: 20
            МГУ, Экономический факультет
            Автор курсов, преподаватель
            08.04.2013 16:01

            Михаил Викторович, спасибо за совет. Так и поступим. Я до конца недели вынужден уехать в командировку на Украину. Как там будет со временем/доступом в Интернет пока не знаю. Поэтому может быть некоторая задержка с ответами. Прошу меня извинить, если что. По заданной теме свои соображения обязательно изложу, как обещал.

          • Дмитрий Капинос Михаил
            Рейтинг: 20
            МГУ, Экономический факультет
            Автор курсов, преподаватель
            23.04.2013 17:48

            Как обещал, изложил свое видение: http://www.globalcio.ru/workshops/107/#/comments/4711/s/ Не совсем понятно, как здесь работает система оповещений (ни одного не получил, хотя галочка в настройках стоит, вроде), поэтому на вс. случай копирую сюда ссылку. Жалко, что картинки нельзя размещать...

            • Михаил Петров Дмитрий
              Рейтинг: 264
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              23.04.2013 20:08

              Странно, у меня оповещения работают...

              • Дмитрий Капинос Михаил
                Рейтинг: 20
                МГУ, Экономический факультет
                Автор курсов, преподаватель
                23.04.2013 20:16

                Может у меня спам-робот их жрёт? ( Надо разобраться...

    • Иван Чалей Дмитрий
      Рейтинг: 10
      ОАО "Сургутнефтегаз"
      Зам.нач-ка управления информационных технологий
      05.04.2013 10:03

      Михаил икторович! Прошу пояснить используемый Вами термин "буллет". Специально посмотрел в Интернете, но не нашел разумных определений. И еще коллеги, так как терминология в архитектуре предприятия (АП) не устоялась, то считаю целесообразным использовать рускоязычные термины пояснениями, или англоязычные в оригинальном написании. Относительно, что такое АП, то здесь необходимо учесть несколько аспектов. Например, . Во-первых, как неотъемлемое свойство любого предприятия - его «устройство». Во-вторых, как совокупность моделей, представляющих описание того, как устроено и работает предприятие. В-третьих, как деятельность, связанная с созданием и использованием архитектурных описаний (как для текущего состояния предприятия, так и для будущего). Архитектура предприятия – это непрерывная практика описания существенных элементов социотехнической организации, отношений этих элементов между собой, а также с внешней средой для понимания сложности и управления изменениями. Перевод нашего специалиста из - Enterprise Architecture Research Forum Definition for EA as defined by EARF // Enterprise Knowledge Engineering and Management (MEKE) Research Group — MEKE Projects Site. — 2013. — http://hufee.meraka.org.za/Hufeesite/collaborations/earf/definition-for-ea-as-defined-by-the-group.

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

        Иван Вацлавович, прошу прощения за неясность. Под буллетом имел ввиду абзац текста - список, форматированный вот таким символом "•". В англоязычном Word такое форматирование называется bullet (правильнее, конечно, наверное на русский транслитерировать как баллит). Соответственно, под "первым буллетом" имел ввиду абзац "•Что такое ИТ-архитектура, архитектура предприятия и зачем этим нужно заниматься?", под вторым - абзац "•Какие, по мнению участников, стандарты, подходы и ПО управления архитектурой зарекомендовали себя с лучшей стороны? С чего нужно начинать построение архитектуры предприятия по-правильному?" и т.д. Спасибо за интересную ссылку! PS. Кстати, есть возможность гиперссылку делать - так удобнее.

      • Дмитрий Капинос Иван
        Рейтинг: 20
        МГУ, Экономический факультет
        Автор курсов, преподаватель
        05.04.2013 16:31

        Согласен. Вообще, существует огромное количество различных определений архитектуры, буквально каждый стандарт вводит собственное. Вот, напр., определения, данные в стандарте TOGAF (v. 9.1): Предприятие (Enterprise) – совокупность организаций, имеющих общий набор целей. Примеры: государственное агентство; корпорация; подразделение корпорации; департамент; сеть географически распределённых организаций, объединённых общим собственником. («TOGAF defines ‘‘enterprise’’ as any collection of organizations that has a common set of goals. For example, an enterprise could be a government agency, a whole corporation, a division of a corporation, a single department, or a chain of geographically distant organizations linked together by common ownership» [TOGAF Version 9.1. Open Group Standard. – Published in the U.S. by The Open Group, 2011. – 692 p. – P. 5.].) Архитектура (используются различные значения термина в зависимости от контекста): 1. Формальное описание системы, или детальный план системы на уровне её компонент для управления её реализацией. 2. Структура компонент, их взаимных связей, принципов и норм их разработки и развития с течением времени. («In TOGAF, ‘‘architecture’’ has two meanings depending upon the context: 1. A formal description of a system, or a detailed plan of the system at component level to guide its implementation 2. The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time» [TOGAF Version 9.1, p. 9].) (На всякий случай привожу оригинальный текст для сверки и точные ссылки.) Практически все они (определения) содержат в своём составе определение системы, ну и вариации относительно неё. Основные вариации, как Вы правильно заметили: сама система, её модель (гипермодель), манипуляции с двумя предыдущими. Я лично считаю, что включение деятельности (по аналогии с архитектурой зданий) в состав и без того размытого понятия совершенно не оправдано. Для описания деятельности/практики могут без каких-либо проблем использоваться термины архитектурных работ (architecture work) или архитектурного процесса (или им подобные). Само же определение архитектуры можно очистить от несущественного и уточнить, если проследить эту практику в развитии. Изложу своё видение на сей счёт, если не сочтёте за занудство, вот только Михаил Викторович подскажет мне, как это лучше сделать.

        • Иван Чалей Дмитрий
          Рейтинг: 10
          ОАО "Сургутнефтегаз"
          Зам.нач-ка управления информационных технологий
          08.04.2013 08:53

          Дмитрий Евгеньевич! Может я Вас не понял, но если из определения исключить понятие "деятельности", то будет исключен и бизнес-домен, а в этом я вижу основную изюминку АП, в противном случае, мы перейдем на методологию представления сервисов бизнесу, а АП - это как обозначено в дискссии - наведение мостов, я бы сказал, что АП дает синергетический эффект от ИТ и инновационных решений в бизнесе, чере АП ИТ может не обслуживать бизнес, а быть равноправным партнером.

          • Дмитрий Капинос Иван
            Рейтинг: 20
            МГУ, Экономический факультет
            Автор курсов, преподаватель
            08.04.2013 15:55

            Иван Вацлавович, я имел в виду слияние в терминологической области понятий архитектуры и архитектурной деятельности. Из состава же архитектуры деятельность/процессы исключать ни в коем случае нельзя. Чуть позже я постараюсь изложить свою точку зрения подробнее. Разумеется, всегда рад критике и уточнениям.

          • Дмитрий Капинос Иван
            Рейтинг: 20
            МГУ, Экономический факультет
            Автор курсов, преподаватель
            23.04.2013 17:51

            Иван Вацлавович, развёрнуто изложил своё понимание по 1-му дискуссионному пункту: http://www.globalcio.ru/workshops/107/#/comments/4711/s/

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    10.04.2013 09:59

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

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

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

      • Марк Шварцблат Михаил
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        10.04.2013 11:11

        Я бы даже сказал - "динамический". Не в динамике сразу возникает разрыв описания (представления) и реальности с потенциальными катастрофическими последствиями. ПО по железу и структуре сети много. От дорогих до бесплатных. Можно выбрать. Список ПО из-под Винды получить тоже можно. Но глубже не видел. Работает - не работает, как предел мечтаний. Если все изменения в Архитектуру делать только через заявку-подтверждение выполнения в неком аналоге сервисдеска, то, вероятно, можно. Думаю, что где-то такое уже реализовано. За бугром.

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

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

          • Марк Шварцблат Михаил
            Рейтинг: 10
            КТ "Акведук"
            ИТ-директор
            10.04.2013 11:51

            Так вот куда переехал филиал рая. Если не секрет - на каком ПО реализовано? Можно в личку, чтобы не делать рекламу забесплатно. :)

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

              Ну, до филиала рая все-таки далеко, но определенную упорядоченность имеем. Название у тебя в личке.

      • Михаил
        05.11.2013 22:55

        Господа, хочу поделиться опытом «документирования архитектуры в различных средствах…»
        Исходная задача: Необходимо было сформировать описание технической структуры ИТ (сервера, технологические станции и их размещение и взаимосвязь) спроецировать ее на ранее составленные и взаимоувязанные описания структур приложений и общесистемного ПО (взгляд ИТ) и структуру бизнес-функций компании (взгляд бизнеса). И, естественно, обеспечить регулярную актуализацию всех описаний.

        Выделенные ресурсы: весь отдел архитектуры (один человек) и девять месяцев. Бюджет на специальный софт и консультантов не выделялся.

        «История успеха» Построить модель, т.е. определить какие данные нужны, трудностей не составило. А потом, как пишут в РДТЕХ, настала пора архитектурной инвентаризации. Понятное дело –пришлось «идти в народ» с вопросами. За редким исключением, все «ответы» были трех типов:
        1.…у меня (моих сотрудников) нет времени
        2.…я (мои сотрудники) делал это уже много раз - возьмите мои материалы (PDF, DOC, DBF, MDB, EXCEL и др. и пр.)
        3.… все это и так будет сделано, когда внедрим CMDB и Service и нечего тратить на это время сейчас.

        К сожалению (или к счастью), но задача была поставлена самым верхним Руководством компании и ее пришлось решать в установленные сроки и с установленным «бюджетом».

        Ключевой фактор успеха: Нам удалось убедить Руководство в том, что данные о конкретных объектах для формирования описания архитектуры должны поставлять должностные лица, отвечающие за эти объекты. Логика рассуждений была следующей:
        1.Элементы (артефакты) архитектуры – это не абстракции, придуманные архитекторами для своих нужд.
        2.За каждым из элементов стоит либо реальный объект или связь (приложения, сервера, площадки и др.), либо решение бизнеса (цель, продукт, проект, KPI, бизнес-процесс др.).
        3.На создание и владение каждым элементом архитектуры компания тратит деньги.
        4.Значит, в компании должны быть лица, ответственные за эти элементы.
        5.Ответственное лицо обязано знать область своей ответственности и в любой момент быть готовым предъявить свои знания руководству (желательно в «письменно виде»). И это никакая не дополнительная нагрузка на ответственных лиц – это их прямые обязанности. После изложения приведенных выше доводов уже никто из ответственных за техническую структуру ИТ не мог ссылаться на свою загруженность или признаться в том, что он не имеет информации о предмете своей ответственности. Таким образом мы выявили источники данных для описания архитектуры и ответственных лиц.

        Что и как было сделано:
        •Договорились с ответственными лицами о формате и регулярности предоставления данных и закрепили договоренности во внутренних регламентах. В регламентах фиксировалась структура и формат предоставляемых данных, регулярность предоставления, получатель и отправитель данных.
        •Написали ETL процедуры, которые обеспечили сбор и очистку данных из первоисточников и размещение собранных данных в хранилище. Для компании и несколько тысяч человек с несколькими сотнями отделений оказалось вполне достаточно решения на VBA и EXCEL.
        •Для визуализации результатов использовали ИНТРАНЕТ сайт, который регулярно переформировывали при изменениях данных в хранилище. ИНТРАНЕТ сайт позволил нам без каких-либо капитальных вложений и специального обучения дать доступ к описанию архитектуры всем заинтересованным лицам

        График и затраты. На подготовку первой законченной версии решения ушло три месяца. Из них на разработку ETL процедур и процедур генерации сайта по хранилищу у исполнителя ушло порядка 10-15 процентов времени. Остальное время на переговоры и настройку процедур очистки данных. Оставшиеся шесть месяцев шла опытная эксплуатация в ходе которой мы:
        - согласовывали регламенты предоставления данных,
        - приучали ответственных лиц следовать регламентам: своевременно предоставлять необходимые данные
        - расширяли модель за счёт добавления новых источников и таких архитектурных артефактов, как:
        •Поставщики ПО и оборудования (данные из Административно-финансового управления)
        •Техническая политика ИТ в части ПО и оборудования (данные из проектного офиса)
        •Затраты на сопровождение ПО собственной разработки (данные из системы учета заявок на доработку ПО)
        •Ответственные за сопровождение и эксплуатацию элементов

        В итоге мы получили:
        •Описание архитектуры предприятия, доступное всем заинтересованным лицам. Единая правда о том, что мы знаем о нашей архитектуре в каждый конкретный момент времени.
        •Работающий процесс формирования и актуализации описания архитектуры предприятия.
        •Возможность наращивать объем архитектурных артефактов по мере того, как процедуры их ведения созреют для включения в регулярный процесс.
        •Персонал, овладевший навыком точно и вовремя поставлять данные.
        •Структурированные данные, которые могут быть загружены в любую промышленною систему поддержки описаний архитектуры предприятия и/или использоваться другими приложениями

        И еще два замечания: Первое. Изложенный выше подход вовсе не предлагается рассматривать в качестве категорической альтернативы использованию для описания архитектуры специального программного обеспечения. Если предприятие располагает доставочным объёмом средств для приобретения и владения специальным ПО, содержания подразделения архитекторов, обучения сотрудников (не только архитекторов) и имеет время на развёртывание процесса ведения описания архитектуры в целом, то нет никаких препятствий для постепенного развертывания высокотехнологичного промышленного решения. Что, собственно говоря, и предлагает инициатор дискуссии. Да и мы сами предпочли бы использовать специальное ПО.

        Второе. Описание архитектуры и проектирование архитектуры – это два совершенно разных процесса. Общее у них только то, что проект архитектуры должен, в общем случае, включать и ее описание. И вообще, ничего революционного в «ПРОЕКТИРОВАНИИ архитектуры предприятия» я не вижу. Вполне естественно, что реализации чего-либо предшествует проект. А назвать его можно и проектом архитектуры. Особенно, если этот «To Be» проект выполнен в той же нотации, что и описание архитектуры предприятия «As Is». Потому как, если эти проекты будут на "разных языках", то никаких мостов ни с кем не навести.

        С уважением, Виктор Жилин.

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    11.04.2013 17:14

    Ten Predictions for Business Architecture in 2020

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

      Как много умных, красивых и правильных (наверное) слов.

      • Марк Шварцблат Михаил
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        12.04.2013 13:05

        Для западного бизнеса вполне все в русле. На ИТ нормально ложится. Но, как говорится, поживём - увидим. :)

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

          ну да

    • Дмитрий Капинос Марк
      Рейтинг: 20
      МГУ, Экономический факультет
      Автор курсов, преподаватель
      23.04.2013 18:57

      Да, интересно. Но имейте в виду, что они там говорят о бизнес-архитектуре, а это только часть архитектуры предприятия: оргструктуры, бизнес-процессы, системы мотивации, стратегические карты и проч. Так сказать, предметная область традиционных консалтинговых компаний. А поскольку они там все сами, включая автора, как я понимаю, бизнес-архитекторы (бизнес-аналитики, консультанты), то не удивительно, что их предсказания по сути сводятся к следующему: значимость бизнес-архитектуры будет возрастать. Хотя кое-что из того, что предсказывается к 2020 г., наверно уже имеет место быть по факту. Напр., 1-й пункт. Поскольку под предприятием могут понимать не только юридически обособленную корпорацию, но и её часть, то и возможность есть формировать архитектуры не только для всей компании в целом, но и для отдельных её подразделений, с учётом специфики, подходящих инструментов и т.д. Во многих случаях это целесообразно. Особенно, если бизнес диверсифицированный.

      • Марк Шварцблат Дмитрий
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        24.04.2013 16:12

        Это понятно. И понятно, что Большая архитектура складывается из кучи маленьких архитектурок. Я это выложил, как пример медитации на тему архитектуры в некоторой ее части.

        • Дмитрий Капинос Марк
          Рейтинг: 20
          МГУ, Экономический факультет
          Автор курсов, преподаватель
          29.04.2013 15:39

          Ну, в общем, да, помедитировать там есть над чем. Комментарии там также информативные.

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

    Как много умных, красивых и правильных (наверное) слов.

  • Сергей Цветаев
    Рейтинг: 10
    1. Закрытое акционерное общество Лаборатория новых информационных технологий «ЛАНИТ»
    Руководитель проектов
    11.04.2013 21:55

    Может встретимся в реале ! Тема всем нравиться, попьем чаю. Обсудим.

    • Михаил Петров Сергей
      Рейтинг: 264
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      12.04.2013 00:14

      Хорошая мысль. Только что касается меня - я временно в Сочи живу - трудновато выбраться в столицу из-за загруза :( так что чай могу попить только по скайпу :) или вы к нам - таки ж Сочи не Колыма :)

      • Илья Подорванов Михаил
        Рейтинг: 10
        РДТЕХ
        Директор центра управленческого и ИТ консалтинга
        12.04.2013 11:25

        Михаил, а я давно не был в Сочи, у меня 10 однокурсников сейчас там, в Вашей структуре работают кстати)

        • Михаил Петров Илья
          Рейтинг: 264
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          12.04.2013 19:10

          Так приезжайте :) тем более - 10 однокурсников... а кто они?

    • Илья Подорванов Сергей
      Рейтинг: 10
      РДТЕХ
      Директор центра управленческого и ИТ консалтинга
      12.04.2013 11:23

      Сергей, а что, отличная идея! Может в начале следующей недели?

  • Сергей Цветаев
    Рейтинг: 10
    1. Закрытое акционерное общество Лаборатория новых информационных технологий «ЛАНИТ»
    Руководитель проектов
    12.04.2013 11:39

    До Сочи точно, не доберусь ! А вот в Первопрестольной с удовольствием. Можно и в начале недели.

  • Илья Подорванов
    Рейтинг: 10
    РДТЕХ
    Директор центра управленческого и ИТ консалтинга
    12.04.2013 11:51

    Тогда на следующей неделе, во вторник нормально?

  • Илья Караваев
    Рейтинг: 10
    РДТЕХ
    Руководитель Практики ИТ-консалтинга
    12.04.2013 13:40

    Что такое ИТ-архитектура, архитектура предприятия и зачем этим нужно заниматься? Если сказать «своими словами», то выстроенная система управления архитектурой предприятия, включает два компонента: I. Репозиторий архитектуры. Он должен включать, в соответствии с выбранной предприятием методологией, описание как минимум приведенных в теме обсуждения предметных областей (доменов). II. Процедур управления АП, которые позволяют актуализировать стратегию и переводить ее в конкретные архитектурные изменения (под архитектурными изменениями можно понимать изменения как в части организации бизнес-процессов, так и в поддерживающих их ИТ-решениях). Эти процедуры организуются в рамках работы коллегиального органа принятия решений - комитета по информатизации, или архитектурного комитета. Архитектурный комитет – это площадка, на которой поддерживается диалог заинтересованных лиц и принимаются «архитектурные» решения. Рассмотрим для начала архитектурный репозиторий. В TOGAF есть, например, такое понятие, как архитектурный артефакт. Под таким «страшным» названием имеются ввиду модели (схемы), таблицы или просто текст, описывающие конкретные аспекты архитектуры, например: • модели в нотациях EPC или BPMN, которые описывают бизнес-процессы (включая логику выполнения и окружение функций – входящие/исходящие документы или данные, используемые приложения, сервисы, исполнители и пр.); • модели классификации информационных систем (портфель ИС), в котором системы разбиты по квадрантам перспективности (например, Перспективные-Стабильные-Вынужденно поддерживаемые-Вытесняемые); • модели поддержки информационными системами бизнес-процессов (например, матрица в разрезах бизнес-процессы/структурные подразделения, в ячейках которой указаны используемые компоненты ИТ-архитектуры); • модели классификации и описания структуры данных; • модели интеграции, потоков данных, коммуникаций; • модели/срезы архитектурных решений, программ и проектов и т.д. Основным свойством архитектурного репозитория является то, что он содержит взаимосвязанное описание бизнес- и ИТ-структур, описание которых отдельно друг от друга имеет очень мало смысла. Кроме того, в репозитории желательно, чтобы имелись технические возможности автоматизированного анализа, формирования выборок информации и проработки версий (вариантов) моделей для построения целевой архитектуры. Конкретный набор типов артефактов зависит от выбранной в организации методологии описания АП и используемого инструментария описания. Для этих целей в РДТЕХ используются два продукта – ARIS IT Architect и Alfabet. Само описание, или документирование архитектуры – процесс довольно трудоемкий и сам по себе, без привязки к конкретной решаемой проблеме или цели (проекту) смысла особого не имеет. Процесс управления АП – итеративный, и более-менее связное описание АП, как правило, получается за несколько итераций разработки по различным проектам. Разработанные архитектурные артефакты просто накапливаются в репозитории и могут быть использованы во всех последующих проектах, как ИТ-, так и чисто организационных изменений. Наличие архитектурного репозитория в компании позволяет как минимум (в т.ч. по оценке deloitte) снизить до 15% затрат на ИТ-проекты за счет наличия уже готовой и систематизированной информации по функциям и поддерживающей ИТ-архитектуре. ПРИМЕР Предположим, что стоит задача разработки/актуализации ИТ-стратегии или концепции автоматизации. Заказчик обычно приглашает внешних консультантов, которые интервьюируют, анкетируют руководство, собирают и систематизируют информацию, формируют варианты решений, где это необходимо, и выдают портфель проектов, направленный на достижение некоторой целевой ИТ-архитектуры. В результате за несколько месяцев рождаются большие по объему документы приблизительно следующего содержания: 1. Цели информатизации 2. Классификация бизнес-процессов общества 2.1. Описание бизнес-процессов в 2.2. Описание бизнес-процессов в 3. Классификация информационных систем 4. Функционально-системная архитектура основных бизнес-процессов 5. Выводы по текущему состоянию ит-обеспечения 5.1. Затраты на текущее ИТ-обеспечение относительно мировых/отраслевых практик 5.2. Оценка состояния ИТ-инфраструктуры 5.3. Организация и инструменты управления ИТ 5.4. ИТ-обеспечение бизнес-процессов общества 5.4.1. Основные информационные системы/бизнес-процессы 5.4.2. Вспомогательные информационные системы/бизнес-процессы 6. Целевое состояние архитектуры предприятия 6.1. Целевая ИТ-инфраструктура 6.2. Целевая система управления ИТ 6.3. Целевая ИТ-архитектура 6.3.1. Подход к трансформации ИТ-архитектуры 6.3.2. Принятые требования и ограничения к ИТ-стратегии и предположения для построения целевой ит-архитектуры 6.3.3. Модель целевой ИТ-архитектуры 6.3.4. Стандарты, программные платформы для реализации целевой ИТ- архитектуры 6.3.5. Интеграция компонентов ИТ-архитектуры 7. Оценка рисков реализации программы проектов 7.1. Оценка внутренних рисков 7.2. Оценка внешних рисков 8. Оценка бюджетов на реализацию пакета инициатив 9. План реализации концепции информатизации 10. Механизмы поддержания стратегии/концепции в актуальном состоянии 10.1. Методика актуализации 10.2. Процедура внесения изменений Стоит разработка такой стратегии для крупной компании соответствующего такой компании бюджета. К концу проекта появляется документ, который а) трудно состыковываемый (разработка обычно ведется несколькими участниками, а затем разделы собираются в один документ) б) уже скорее «мертвый», чем живой, т.к. уже может и ландшафт процессов за полгода поменялся, какая-нибудь «неожиданная» стратегическая цель появилась :) Кроме того, информация в «сухом» документе – это еще далеко не знания и представления о том, в каком направлении надо развивать ИТ в компании конкретных людей, участвующих в этом. Реально выработать это представление у участников можно только одним способом- вовлечь их в процесс разработки ИТ-архитектуры и стратегии. Прочитав «тяжелый» документ по ИТ-стратегии они, как правило, не получают такого представления (личное мнение :)). Если посмотреть в приведенное содержание, такой документ по сути является набором последовательных действий по актуализации или построению архитектурных моделей, срезов или выборок по интересующим вопросам. Этот набор действий можно назвать «сценарий использования» («use case»). Разработка стратегии – не единственный сценарий. Такими сценариями в рамках общей методологии управления архитектурой предприятия могут быть: • Описание и регламентация отдельных бизнес-процессов (как часть работ СМК с использованием репозитория); • Описание ИС и данных; • Оценка перспективности для компании существующих на рынке решений (в компаниях как правило нет четких критериев, прозрачного процесса для оценки перспективности какого-либо ПО на рынке) • Формирование архитектуры ИТ-решения и требований к нему в рамках к-л функциональной области/процесса и т.д. • Управление бюджетными статьями, программами/портфелем проектов • Мониторинг проектов и др. Каждый Use case представляет собой процесс манипуляций над архитектурными артефактами из репозитория. Участниками процесса могут являться бизнес-аналитики, участники системы менеджмента качества, владельцы бизнес-процессов, менеджеры по изменениям, руководители проектов, бизнес- и ИТ-архитекторы CIO, CFO и прочие заинтересованные в эффективной деятельности персоны… Все эти люди - потребители и заинтересованные стороны в развитии подходов АП... Обратите внимание, что п.10 приведенной структуры (Механизмы поддержания стратегии/концепции) в актуальном состоянии – это предложение поддерживать актуальным очень большой документ, и реально я очень сомневаюсь, что в компаниях эти процедуры реально работают. А вот процедуру актуализации четко заданного количества моделей архитектуры предприятия в определенной логикой построения последовательности (как одного из Use Cases) я себе могу представить вполне четко. Периодическая реализация такой последовательности уже в виде процесса внутри компании (а не проекта внешних консультантов) под надзором архитектурного комитета – это в общем и есть разработка ИТ-стратегии, в результате которой стратегическое видение, понимание ситуации и того, что нужно делать, - появляется в голове самих сотрудников организации. Внешние участники в процессе разработки АП или стратегии (консультанты) нужны не для интервьюирования руководства компании и систематизации информации в красивой форме, а как эксперты по конкретным классам ИТ-решений, технологиям или конкретным продуктам, чтобы в рамках их анализа отловить, понять и применить реально работающие инновационные решения и технологии в критичной для конкретной компании области...

    • Михаил Петров Илья
      Рейтинг: 264
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      16.04.2013 10:27

      Спасибо! Предметная область теперь понятна :) И дан практически ответ на первый вопрос дискуссии - "что это такое и зачем этим заниматься" :) Вопрос. Все это достаточно трудоемко = стоит денег. По Вашему опыту - в каких ситуациях компании действительно стоит их тратить, т.е. отсутствие такой деятельности может быть дороже, чем ее поддержание в актуальном состоянии? И наверное подходы к такой деятельности определяются именно "масштабом" развертывания архитектурных работ.

      • Илья Караваев Михаил
        Рейтинг: 10
        РДТЕХ
        Руководитель Практики ИТ-консалтинга
        23.04.2013 09:27

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

        • Михаил Петров Илья
          Рейтинг: 264
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          23.04.2013 10:02

          Все таки - для разработки ИТ-стратегии нет необходимости погружаться так глубоко в архитектурные вопросы... А кроме ИТ-стратегии - есть примеры?

          • Илья Караваев Михаил
            Рейтинг: 10
            РДТЕХ
            Руководитель Практики ИТ-консалтинга
            23.04.2013 10:30

            Михаил Викторович, я бы выделил несколько ситуаций, в которых можно выйти на создание таких репозиториев или «архитектурных» офисов: 1. В компании планируется или идет крупный проект внедрения корпоративной информационной системы. Взаимосвязанное управление архитектурой решения и требованиями к ИС способны дать экономию до 20% за счет сокращения объема работ по некорректным требованиям, переделкам 2.В компании могут планироваться крупные изменения (слияние или поглощение, открытие филиалов/представительств, приобретение активов, открытие новых направлений бизнеса и т.п.). Реально во всех таких ситуациях из-за сложности и тесной взаимозависимости ИТ с процессами необходимо описание и систематический анализ архитектуры, стандартизация процессов. Как правильно было отмечено, преимуществом подхода АП является проектирование ИТ во взаимосвязи с бизнес-процессами и целями 3.Большое количество информационных систем (зоопарка) при наличии проблем автоматизации в какой-либо функциональной области. По моему мнению, наличие механизмов стандартизации ИТ-инфраструктуры и выбора приоритетных инвестиций в ИТ экономит до 30% ресурсов. Это чисто архитектурные задачи, решаемые на таких совместных площадках по управлению архитектурой. А «источником правды» для принятия решений в области стандартизации и пр. может быть репозиторий, где все процессы, показатели, цели, возможности ИС, их текущая архитектура и т.д. задокументированы

            • Илья Караваев Илья
              Рейтинг: 10
              РДТЕХ
              Руководитель Практики ИТ-консалтинга
              23.04.2013 10:33

              Михаил, интересная новость в качестве примера для обсуждения МГТС меняет SAP на Oracle

              • Михаил Петров Илья
                Рейтинг: 264
                Счетная палата Российской Федерации
                Директор департамента цифровой трансформации
                23.04.2013 12:02

                Илья, сорри - не уловил связи с темой... поясните?

            • Михаил Петров Илья
              Рейтинг: 264
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              23.04.2013 12:00

              Да, это понятно. Уточню вопрос - каковы критерии "крупности", "зоопарка"? Вот у меня, например, порядка 30 систем внедряется. И мы не ощущаем потребности в такого рода в подробном и сложном документировании. Но наш случай, мне кажется, нетипичный. А вот из Вашего опыта - когда "уже пора"?

              • Дмитрий Капинос Михаил
                Рейтинг: 20
                МГУ, Экономический факультет
                Автор курсов, преподаватель
                23.04.2013 19:21

                А почему сложном-то? Задача наоборот сделать максимально просто и понятно: разбить сложное и большое на куски, описать в стандартной нотации, показать как те куски между собой взаимодействуют и каким целям бизнеса соответствуют. Вот участник здесь приводил ссылку, так там об этом же. Что касается "зоопарка", то зоопарк, это не когда много систем, и не когда осуществляются масштабные внедрения. А когда, представьте, внедрялись они разными людьми, отделами, организациями в разные годы, под различные задачи (возможно конкурирующие), под различное видение того, что должно в итоге получиться. Эти люди (руководители, разработчики), отделы менялись. Внедрение или не документировалось или документировалось плохо. Цели и предназначение ИС частично утеряны (изменились бизнес-функции, процессы и т.д.). Кто отвечает за поддержку систем -- не понятно. Интеграция -- кошмар. Снести всё и построить заново нельзя, т.к. всё числится как инвестиции (зачастую недешёвые, тот же пресловутый SAP, напр.). И т.д. Тут, чтобы что-то просто начать делать, прийдётся сначала разбираться, как это всё устроено, кто виноват отвечает за что и проч. Чтобы распутать этот клубок не обойтись без какого-то описания, моделей, набросков, обсуждения, объяснения дальнейших действий (может быть недешёвых) лицам, принимающим решения, и т.д. Это, конечно, можно сделать на бумаге, договорившись о терминах. Но можно и с помощью специально заточенного под подобные задачи фреймворка, со стандартными нотациями, понятными и бизнесу и айтишникам, инструментами и проч. Причём это всё будет храниться в такой форме, что при должной и не столь уж сложной актуализации эту работу не прийдётся по-новой повторять, скажем, через 5+ лет, когда появятся новые модные ИТ-находки и прийдёт новый амбициозный топ-менеджер с идеями радикальной реорганизации. Архитектура в этом случае по сути дела актив, а в бумажках тех через какое-то время даже сам автор не разберётся.

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

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

                  • Дмитрий Капинос Михаил
                    Рейтинг: 20
                    МГУ, Экономический факультет
                    Автор курсов, преподаватель
                    23.04.2013 21:05

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

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

                      Я разве предлагаю снести? Я ровно про то что надо оценивать с учётом конкретной ситуации, с учётом и оценкой рисков.

                      • Дмитрий Капинос Михаил
                        Рейтинг: 20
                        МГУ, Экономический факультет
                        Автор курсов, преподаватель
                        23.04.2013 21:43

                        Ну, да, согласен. Если дешевле поменять, чем документировать, то, возможно, так и надо сделать.

                    • Марк Шварцблат Дмитрий
                      Рейтинг: 10
                      КТ "Акведук"
                      ИТ-директор
                      24.04.2013 17:45

                      Дайте потрогать руками систему, где можно просто и без лишних трудозатрат описывать имеющиеся комплексы и их связи, где есть дрилдаун и внятная визуализация, где есть автоматически сбор ХОТЯ БЫ половины нужной информации.Не видел я таких систем. Про интеграцию с КИС вообще молчу. И это только одна сторона медали. Есть еще сотрудники, которых крайне проблематично заставлять в положенные сроки вносить в описание сделанные изменения.

                      • Дмитрий Капинос Марк
                        Рейтинг: 20
                        МГУ, Экономический факультет
                        Автор курсов, преподаватель
                        29.04.2013 16:20

                        «Дайте потрогать руками систему, где можно просто и без лишних трудозатрат описывать имеющиеся комплексы и их связи, где есть дрилдаун и внятная визуализация...» Пожалуйста: ARIS IT Architect, напр. Всё это там есть. А если чего-то нет, можно дописать. Он имеет модульную организацию и есть возможность реализовывать различные функции на JavaScript. Другой возможный пример: SAP Solution Manager, о котором здесь говорит коллега. Он позиционируется как средство разработки информационных решений для бизнеса. Насколько он прост и малозатратен, сказать не могу. Сам не сталкивался. «...где есть автоматически сбор ХОТЯ БЫ половины нужной информации.Не видел я таких систем». А вот этого требовать от программных инструментов архитектурного проектирования концептуально неверно. Если рассуждать логически. Если вы реализуете ИТ-инструмент для бизнеса с нуля или разбираетесь с исторически сложившейся ИТ-стихией на предмет создания такого инструмента, то никакой робот за вас проблему целеполагания и соответствия не решит. В любом случае понадобиться человек, не просто человек, а эксперт. Причём потребуется не просто профессиональный уровень знаний, а знание конкретики, знание и понимание текущей ситуации. Первым шагом любых подобных работ будет проектирование. Один из подходов здесь -- архитектурный. Если же у вас такая система, которая по запросу предоставляет своё описание (причём с учётом требуемых перспектив и точек зрения: для кого инфо -- для акционеров, ГД, ИТД, аудита и т.п.), то скорее всего архитектура в той или иной форме у вас уже есть, и смысла переизобретать её особого нет. Но это, конечно, из области фантастики (по объективным причинам). «Про интеграцию с КИС вообще молчу». Интеграция с КИС отдельная тема. Во многих случаях она, в общем-то, и не особо нужна. А там где нужна, разработчики серьёзных КИС сами предлагают средства такой интеграции (те же BPM системы, напр.). «Есть еще сотрудники, которых крайне проблематично заставлять в положенные сроки вносить в описание сделанные изменения». Это правда. Такая проблема есть. Но она вполне решаемая. Прежде всего, зачем заставлять? Может мотивировать, напр.? Правильный подход, вообще, не нагружать непрофильные отделы такими обязанностями, не вешать это, напр., на айтишников, как дополнительную повинность, а создать отдельное функциональное подразделение по АП, для сотрудников которого эти обязанности будут прописаны в должностных инструкциях, завязаны на соотв. показатели и проч.

                        • Марк Шварцблат Дмитрий
                          Рейтинг: 10
                          КТ "Акведук"
                          ИТ-директор
                          30.04.2013 10:58

                          Вроде бы как по цене ARIS не для российского среднего бизнеса (малый вопросами архитектуры не заморачивается). Я могу нафантазировать и напроектировать много чего. Дело не в установке целей. Дело в том, что СБОР и приведение в формализованный божеский вид информации о имеющейся архитектуре занимает львиную долю РУЧНОГО труда и вносит очень заметную долю ошибок. Про интеграцию с КИС еще раз напишу (вероятно ранее написал малопонятно). КИС уже частично формализует БИЗНЕС-архитектуру. Де-факто, единая КИС или их комплекс наиболее формализованная часть обычного бизнеса (не телекоммуникации или ИТ). Заставлять - это добиваться результата. :) Мотивацией или другими способами - вопрос тактический. Но склоняюсь к мнению, что т.к. это формальная процедура, то мотивировать рублем в виде штрафа за невыполнение регламента.

                          • Дмитрий Капинос Марк
                            Рейтинг: 20
                            МГУ, Экономический факультет
                            Автор курсов, преподаватель
                            30.04.2013 12:19

                            Да, ARIS для среднего и малого бизнеса может быть дороговат. С другой стороны, уровень сложности там скорее такой, что можно обойтись более бюджетными решениями. Возможно свободно распространяемого ARIS Express или MS Visio будет достаточно. Есть ещё российская разработка Business Studio, напр. По ценам, вроде, доступная. Насколько функциональная -- сказать не могу (руками пока не трогал). Ещё должны быть open source решения. Надо этот вопрос исследовать. Спасибо за наводку, кстати. «Дело в том, что СБОР и приведение в формализованный божеский вид информации о имеющейся архитектуре занимает львиную долю РУЧНОГО труда и вносит очень заметную долю ошибок». Конечно. И мы на этом специализируемся (в смысле: на труде, не на ошибках). Когда это со временем станет простым и понятным делом для всех, нам прийдётся искать другое занятие. ) Или будем, напр., ходить и жалостливо просить милостыню: «Подайте бывшему консультанту бывшего управленческого и ИТ-консалтинга!» (шутка). Знаете, как раньше была специальная профессия писцов, когда никто читать/писать не умел. Теперь все умеют, профессии такой нет. Про КИС Сформировать какую-то часть текущей бизнес-архитектуры на основе существующих ИТ-систем, в которых отражена текущая деятельность, это правильно. Может быть существенная экономия усилий, повторное использование сделанных наработок. Но, на вс. случай оговорюсь, идти к бизнес-архитектуре от КИС в подавляющем большинстве случаев методологически неверно (могут быть исключения). Откуда Вы, напр., знаете, что ваша КИС делает именно то, что нужно бизнесу? Насколько соответствует? Бизнес должен определять ИТ, а не наоборот. В противном случае получается ставить телегу впереди лошади. Максимум, на что мы можем рассчитывать, извлекая модели из формальных описаний существующих систем, это элементы бизнес- и ИТ-архитектур «как есть». После этого, всё равно, должны садиться аналитики/архитекторы и серьёзно думать над этим: а как должно быть? а что не так? и т.д. (про труд, см. выше). Причём нужно понимать, что перед участниками архитектурных работ здесь стоит задача не достичь совершенства, а выработать некоторое приемлемое субоптимальное, экономически оправданное решение. С инкрементальными улучшениями в последующих циклах архитектурных работ (сами архитектурные работы должны вестись на постоянной основе, т.к. ситуация, требующая соотв. архитектуры, постоянно меняется). «Но склоняюсь к мнению, что т.к. это формальная процедура, то мотивировать рублем в виде штрафа за невыполнение регламента». Авторитаризм! ) А если ценные кадры разбегутся?

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

                              MS Visio замечательный инструмент, но не для командной работы и все-таки по функционалу не очень заточен на такие задачи. А насчет Откуда Вы, напр., знаете, что ваша КИС делает именно то, что нужно бизнесу? - хороший вопрос. Может быть, если она что-то не делает - то бизнес сам придет и скажет? нужно ли для ответа на этот вопрос углубляться в архитектурные "дебри"? Я не то чтобы против, просто пытаюсь понять аргументацию... :)

                              • Марк Шварцблат Михаил
                                Рейтинг: 10
                                КТ "Акведук"
                                ИТ-директор
                                30.04.2013 12:41

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

                                • Михаил Петров Марк
                                  Рейтинг: 264
                                  Счетная палата Российской Федерации
                                  Директор департамента цифровой трансформации
                                  30.04.2013 14:10

                                  ну это понятно :)

                                • Дмитрий Капинос Марк
                                  Рейтинг: 20
                                  МГУ, Экономический факультет
                                  Автор курсов, преподаватель
                                  07.05.2013 17:28

                                  Работу архитектурного проектирования система сделать не может. Это в светлом постапокалиптическом будущем пока, аля Терминатора и Матрицы. Даже модные консультанты со стороны эту работу без вовлечения владельцев и участников предприятия и за них сделать не могут. В том числе и решить будут там заниматься этой работой или не будут. Им решать.

                                  • Марк Шварцблат Дмитрий
                                    Рейтинг: 10
                                    КТ "Акведук"
                                    ИТ-директор
                                    08.05.2013 09:42

                                    Не спорю. Но проектирования. Не сбора сырых первичных данных.

                                    • Михаил Петров Марк
                                      Рейтинг: 264
                                      Счетная палата Российской Федерации
                                      Директор департамента цифровой трансформации
                                      08.05.2013 11:05

                                      А что значит "сбора сырых первичных данных"? какая-то система это может?

                                      • Марк Шварцблат Михаил
                                        Рейтинг: 10
                                        КТ "Акведук"
                                        ИТ-директор
                                        08.05.2013 11:08

                                        Нет. Но хочется. Я уже много раз писал. А-ля сбор сетевой и серверной архитектуры.

                                        • Михаил Петров Марк
                                          Рейтинг: 264
                                          Счетная палата Российской Федерации
                                          Директор департамента цифровой трансформации
                                          08.05.2013 11:37

                                          Понял. Чтобы переткнул патч-корд, а оно само задокументировалось :)

                                          • Марк Шварцблат Михаил
                                            Рейтинг: 10
                                            КТ "Акведук"
                                            ИТ-директор
                                            08.05.2013 11:52

                                            Только в части бизнес-процессов и КИС. :)

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

                                              Ну тут точно только искусственный интеллект

                              • Дмитрий Капинос Михаил
                                Рейтинг: 20
                                МГУ, Экономический факультет
                                Автор курсов, преподаватель
                                07.05.2013 17:22

                                Задачи ведь могут быть разные. Чтобы разобраться и задокументировать систему в иных случаях будет достаточно не то, что Visio, но и обычных листов бумаги. Раньше, кстати, так и делали, причём проекты были космической сложности (в прямом и переносном смысле). Другое дело, что это не так удобно, как специализированный инструмент. Но тут, опять, вопрос экономической целесообразности (мы же, конкретно здесь, говорим про малый и средний бизнес, который не одобряет дороговизну решений для архитектурного проектирования, -- я с этим согласен, кстати). На счёт мнения бизнеса. Конечно, он просто обязан это сделать, с этого и следует начинать. На основе этого "скажет" в существенной части и строится бизнес-архитектура. "Дебри"-то, как раз, до архитектурной формализации. Часто бизнес сам явно не знает, что хочет в итоге, "нутром чует", что не так, а не знает что. Бывает, возьмёшь декларацию о стратегических целях какой-нибудь уважаемой крупной компании, читаешь и понять не можешь, что написано: вроде по-русски, вроде грамматически корректно и даже складно-мелодично, а о чём -- не понятно. Птичий язык с минимумом содержания. Часто бизнес не видит всей картины. Он тоже не однороден, тоже разделение труда, различные точки зрения. Но ещё хуже, что как правило существуют объективно разные интересы различных групп и разные мнения, которые запросто могут противоречить друг другу (лебедь, рак и щука получаются). Только чтобы это выяснить, надо уже собрать и систематизировать мнения. Потом же их надо взвесить, выверить и прийти к какому-то общему соглашению относительно целей. И только после этого можно начинать думать об ИТ.

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

                                  Полностью согласен

                            • Марк Шварцблат Дмитрий
                              Рейтинг: 10
                              КТ "Акведук"
                              ИТ-директор
                              30.04.2013 12:47

                              Business Studio посмотрю. Спсб. Visio и эрзацев из OpenOffice не хватает. Уже проходили. Сторонних консультантов тоже уже проходили. Они очень много времени потратили на то, чтобы начать разбираться в конкретной предметной области розничной торговли. А их попытки разобраться в производстве вызывали смех. Если КИС делает не то, что надо, то КИС не используют, а делают вручную, но бегут треботь доработок функционала. в данном случае человеческая лень имеет ярко выраженный положительный эффект. КИС делалась и делается не велением и хотением ИТ-подразделения, а исключительно по заказу бизнеса. Если разбегутся - то такова селяви. :) Или кадры были неценные. :)

                              • Дмитрий Капинос Марк
                                Рейтинг: 20
                                МГУ, Экономический факультет
                                Автор курсов, преподаватель
                                07.05.2013 17:57

                                =Visio и эрзацев из OpenOffice не хватает. Уже проходили.= Не знаю специфики вашей компании и ситуации, ничего не могу сказать. Но часто бывает так, что проблема не в негодном инструменте, а в методологической недостаточности. Помните, такой замечательный фильм раньше был "Приключения Петрова и Васечкина"? Там была песенка примерно с такими словами: ...Ни на что не годная скрипка, Я с досады тогда решил, И чужой босоногой девчонке Во дворе её подарил. А девчонка взяла эту скрипку, А девчонка взяла смычок. Зазвучала такая музыка, что В себя я прийти не смог. И скрипка эта звучала Всё чище и всё сильней, Просто-напросто дело не в скрипке, А в том, кто играет на ней. =Сторонних консультантов тоже уже проходили. Они очень много времени потратили на то, чтобы начать разбираться в конкретной предметной области розничной торговли. А их попытки разобраться в производстве вызывали смех.= Очень часто сотрудники и руководство компаний, привлекающих консультантов, совершают фатальную ошибку. Они ждут, что со стороны прийдут могущественные консультанты и всё за них разгребут, что они сами не смогли до сих разгрести. При этом к консультантам отношение как к конкурентам, дескать, посмотрим, как вы справитесь. Это одна из основных причин краха проектов и зря потраченных денег и времени (как своих так и чужих). Консультанты, в принципе, не могут разбираться в конкретике на местах лучше специалистов на местах. Иначе таких специалистов на местах давно бы уже ликвидировали за ненадобностью, остались бы одни летучие бригады консультантов. Задача консультанта (как это следует уже из самого названия) -- консультировать, помогать спецам на местах решать проблемы, привнося в проект знание методологий (от общих до специальных), соотв. инструментов и т.п. Для этих целей всегда создаются сводные проектные группы, в которых спецы компании тесно сотрудничают с консультантами (поддерживают друг друга, пинают друг друга, если необходимо, обогащают друг друга знаниями). А чудес не бывает, за этим лучше к Гарри Поттеру, не к консультантам.

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

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

                                  • Дмитрий Капинос Михаил
                                    Рейтинг: 20
                                    МГУ, Экономический факультет
                                    Автор курсов, преподаватель
                                    22.05.2013 17:48

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

                                • Марк Шварцблат Дмитрий
                                  Рейтинг: 10
                                  КТ "Акведук"
                                  ИТ-директор
                                  08.05.2013 09:52

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

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

                                    Да. Чтобы адекватно выбирать - надо примеры проектов смотреть. А этого никто не покажет - "коммерческая тайна". И привет.

                                    • Марк Шварцблат Михаил
                                      Рейтинг: 10
                                      КТ "Акведук"
                                      ИТ-директор
                                      08.05.2013 11:56

                                      И даже отзывы на сайте не спасают. А вот в живом общение за рюмкой чая такое вываливается. :) Как-то ездил на аудит проекта по внедрению Аксапты лет 6 назад. Заключение сделали. Проект переделывали примерно на половину. Другой подрядчик. Но у первичного проект так и был в "успешных".

                                      • Михаил Петров Марк
                                        Рейтинг: 264
                                        Счетная палата Российской Федерации
                                        Директор департамента цифровой трансформации
                                        08.05.2013 13:02

                                        Конечно в успешных - видимо, успешно взяли бабки и унесли ноги. Я видел случаи когда на деле было сделано раза в 2 меньше, чем казалось из релиза... ничто не спасает кроме терморектального криптоанализатора...

                                        • Марк Шварцблат Михаил
                                          Рейтинг: 10
                                          КТ "Акведук"
                                          ИТ-директор
                                          08.05.2013 13:47

                                          И массовых расстрелов... :)

                                          • Михаил Петров Марк
                                            Рейтинг: 264
                                            Счетная палата Российской Федерации
                                            Директор департамента цифровой трансформации
                                            08.05.2013 14:13

                                            тоже не спасает как показывает практика

                                            • Марк Шварцблат Михаил
                                              Рейтинг: 10
                                              КТ "Акведук"
                                              ИТ-директор
                                              08.05.2013 14:18

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

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

                                                политика. стоп :)

                                                • Марк Шварцблат Михаил
                                                  Рейтинг: 10
                                                  КТ "Акведук"
                                                  ИТ-директор
                                                  08.05.2013 15:14

                                                  При чем тут политика? Я про руководство большим коллективом сугубых программистов-индивидуалистов... :)

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

                                                    Да, точно. Извини, параною :)

                                        • Дмитрий Капинос Михаил
                                          Рейтинг: 20
                                          МГУ, Экономический факультет
                                          Автор курсов, преподаватель
                                          22.05.2013 18:11

                                          Если "взяли бабки и унесли ноги", и это не закончилось "терморектальным криптоанализатором" и "массовыми расстрелами", значит кто-то добрый со стороны заказчика им в этом помогал (=был в доле).

                                  • Дмитрий Капинос Марк
                                    Рейтинг: 20
                                    МГУ, Экономический факультет
                                    Автор курсов, преподаватель
                                    22.05.2013 18:05

                                    Безусловно должен разбираться в предметной области. Но я говорю про конкретику. Потому, что предметная область предметной областью, а завёрнуто там в узел всё может быть так, что без поллитры... И какой выход? Либо сидеть и тратить время на догадки типа "Это недоработка или есть невидимая сразу причина, по которой это сделано намеренно?" Либо пойти к участникам проектной группы от заказчика и прямо их спросить об этом. Я считаю, что правильный второй вариант. Ошибкой руководство было выбор консультантов на основе красивых материалов на концеренциях и сайтах. Да, есть такое. Оч. распространённая проблема. В экономике, если память не изменяет, называется "проблема лимонов", когда сразу при покупке не понятно с каким товаром имеешь дело -- качественным или наоборот, и приходится ориентироваться по каким-то косвенным признакам (сигналам). Этим, разумеется, нехорошие люди пользуются. В том же фильме был и такой стишок: "Неважно быть, сумей прослыть -- не беда! Неважно быть, сумей прослыть, и тогда Повсюду ждет тебя почет, а забот -- Никаких и никогда". К сожалению, в современной экономике это весьма распространено (шоу маст го он), а в консалтинге особенно. Увы. Но, если подходить к делу серьёзно, то: стрелянного воробья на мякине не проведёшь. )

                                    • Марк Шварцблат Дмитрий
                                      Рейтинг: 10
                                      КТ "Акведук"
                                      ИТ-директор
                                      22.05.2013 18:32

                                      У каждого были грабли, на которые он наступил... Главное - на одну модель грабель не более одного раза... :)

                                      • Дмитрий Капинос Марк
                                        Рейтинг: 20
                                        МГУ, Экономический факультет
                                        Автор курсов, преподаватель
                                        22.05.2013 18:43

                                        Именно. ) Называется опыт. )

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

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

                            • Марк Шварцблат Михаил
                              Рейтинг: 10
                              КТ "Акведук"
                              ИТ-директор
                              30.04.2013 12:40

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

                              • Михаил Петров Марк
                                Рейтинг: 264
                                Счетная палата Российской Федерации
                                Директор департамента цифровой трансформации
                                30.04.2013 14:11

                                в какой системе? фиксирует изменения в регламенте, по его заказу делают доработку или донастройку если процесс выдачи разрешения на отгрузку автоматизирован - убирают согласование. все, собственно.

                                • Марк Шварцблат Михаил
                                  Рейтинг: 10
                                  КТ "Акведук"
                                  ИТ-директор
                                  30.04.2013 14:36

                                  Вооот... В какой системе? Сейчас это делается двояко - там, где КИС не задейстована - пишется письмо, которое благополучно теряется, забывается, игнорируется. Или пишется заявка на доработку, ИТ делает, но потом идет шквал звонком и вопросов - куда делась пимпочка на согласование. Вот где-то как-то это должно быть зафиксировано. Служебка в СЭД - не панацея. В общем - не знаю. Сложный вопрос.

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

                                    Там где КИС не задействована - просто меняется регламент. Где задействована - у нас это заявка на сервис-деск, реализация, тестирование, документирование, перенос на рабочую базу (на самом деле иногда - в зависимости от доработки - еще и регламент меняется параллельно и запускается все вместе, и доработка и новый регламент). В сервис-деске все следы есть (ТЗ, документация прикладывается к заявке). Не скажу, конечно, что это идеальный путь, но нам "красивее" и "документированнее" просто в текущей ситуации не надо.

                                    • Марк Шварцблат Михаил
                                      Рейтинг: 10
                                      КТ "Акведук"
                                      ИТ-директор
                                      30.04.2013 15:09

                                      Нормально. Ну вы начинали с нуля - можно было выстроить систему "как надо". У вас нет системы, в которой сведены все описания архитектуры. :)

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

                                        Да и не с нуля можно так выстроить если озаботиться... А системы для архитектуры не было - реально не оправданна в наших условиях, слишком все динамично, "с колес", без достаточного количества ресурсов... приходилось брать не "порядком", а "классом". Сейчас можно бы и озаботиться - но уже смысла нет, меньше года осталось.

                                        • Марк Шварцблат Михаил
                                          Рейтинг: 10
                                          КТ "Акведук"
                                          ИТ-директор
                                          30.04.2013 15:55

                                          У вас особый проект с четким границами. Ну и как обычно в нашей стране - сплошное аджиле... :)

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

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

                                            • Марк Шварцблат Михаил
                                              Рейтинг: 10
                                              КТ "Акведук"
                                              ИТ-директор
                                              30.04.2013 16:36

                                              Обычно - да. У вас - дедлайн четкий. Да я из той дискуссии практически не выхожу. :)

                                              • Михаил Петров Марк
                                                Рейтинг: 264
                                                Счетная палата Российской Федерации
                                                Директор департамента цифровой трансформации
                                                30.04.2013 18:27

                                                Дедлайн конечно четче некуда. А вот границы проектов и пути достижения цели в условиях массы ограничений, которых нет в обычных компаниях, могут быть весьма и весьма витиеваты. А в дискуссии мало появляешься, мало :)

                                                • Марк Шварцблат Михаил
                                                  Рейтинг: 10
                                                  КТ "Акведук"
                                                  ИТ-директор
                                                  30.04.2013 18:33

                                                  Ну дык Олимпиада сама по себе редкость. :) Исправлюсь... :)

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

                                                    Редкость, ага :) Давай :)

                                    • Дмитрий Капинос Михаил
                                      Рейтинг: 20
                                      МГУ, Экономический факультет
                                      Автор курсов, преподаватель
                                      07.05.2013 18:10

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

                                      • Михаил Петров Дмитрий
                                        Рейтинг: 264
                                        Счетная палата Российской Федерации
                                        Директор департамента цифровой трансформации
                                        07.05.2013 20:04

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

                                        • Дмитрий Капинос Михаил
                                          Рейтинг: 20
                                          МГУ, Экономический факультет
                                          Автор курсов, преподаватель
                                          22.05.2013 18:15

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

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    13.04.2013 10:14

    Спасибо. Интересно. Т.е., если я правильно понял, то в любом случае связь моделей-описаний с реальностью - это ручной труд пользователей. И сразу возникает пвопрос - как их контролировать на предмет адекватности внесенных моделей. Если другим человеком, то он должен в предметной области разбираться не хуже создателя. у нас в реальности с большим трудом удавалось поддерживать адекватное описание техонологии розничных продаж, т.к. на эту технологию большое влияние оказывает, к примеру, текущая маркетинговая активность. Да даже небольшие перепланировки магазинов уже влияют на модель для текущей торговой точки. А при высоком уровне абстракции получается документ ни о чем. Что-то крутится в голове из серии - если корпоративная ИС документоориентированная и вооще в компании успешно работает СЭД, то нельзя ли из них получить какие-то модели сразу? В успешных проектах появился проект Управление ИТ-архитектурой ОАО «РЖД» реализованный в том числе средствами ARIS.

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

      Хоть Aris. Хоть не Aris. Труд по поддержанию актуальности все равно ручной, и проблема адекватности никуда не девается, увы :(

      • Марк Шварцблат Михаил
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        13.04.2013 12:59

        Ну вот мне и кажется, что где-то на уровне смычки систем описания и моделирования и текущих КИС что-то должно вырасти. Вот можно вспомнить - сколько времени уходило на документирование и структурирование кода, пока не появилось специализированное ПО. "Скармливаешь" код, а тебе выдается структура, связи, передача параметров, все выравнивается и делается место под комментарии.

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

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

          • Марк Шварцблат Михаил
            Рейтинг: 10
            КТ "Акведук"
            ИТ-директор
            18.04.2013 13:33

            Предпочитаю? Смотря для чего и в какое время суток. :) В части разработки ПО - я сейчас программирую крайне редко и вне рамок больших проектов.

        • Дмитрий Капинос Марк
          Рейтинг: 20
          МГУ, Экономический факультет
          Автор курсов, преподаватель
          23.04.2013 20:27

          Подождите-ка, а Вы не BPM-системы ли часом имеете в виду? Такие, как jBMP (open source/СПО) или Oracle BPM?

          • Марк Шварцблат Дмитрий
            Рейтинг: 10
            КТ "Акведук"
            ИТ-директор
            24.04.2013 16:25

            Нет. Но если консультанты их и могут использовать для описания и моделирования, то как это стыковать с товарными и денежными документами в КИС?

            • Дмитрий Капинос Марк
              Рейтинг: 20
              МГУ, Экономический факультет
              Автор курсов, преподаватель
              29.04.2013 16:47

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

              • Марк Шварцблат Дмитрий
                Рейтинг: 10
                КТ "Акведук"
                ИТ-директор
                30.04.2013 11:12

                1. Процессы в нашей жизни, чаще всего, достаются нам по факту и никакие архитекторы к ним руки не прикладывали. :) 2. Эти процессы, чаще всего, уже реализованы в КИС. 3. Тонкие клиенты для среднего бизнеса скорее исключение (сужу по своей области). 4. Дело не в передаче информации, а в получении "слепка" текущей архитектуры - аппаратной, программной, документооборотной.

                • Дмитрий Капинос Марк
                  Рейтинг: 20
                  МГУ, Экономический факультет
                  Автор курсов, преподаватель
                  30.04.2013 12:38

                  1. Очень неправильно вы поступаете! ) 2. Наличие каких-либо наработок -- это хорошо. Будет за что зацепиться, и, возможно, сэкономит массу усилий и времени (хотя, конечно, зависит от качества наработок, а то может быть и наоборот). 3. Тонкие клиенты -- будущее. Я имею в виду не железо (терминалы vs PC), а ПО (работа через браузер). С помощью тонкого клиента, помимо прочего, можно отвязаться от железа и работать в системе хоть с десктопа, хоть с планшета. 4. Описание текущей архитектуры -- задача аналитиков и архитекторов. Преимущественно ручной труд. Диагностика. Так же как труд доктора, напр. (разница только в объектах исследования, по существу одно и то же). + Проектирование. Что-то, конечно, удаётся автоматизировать, но сути это не меняет. Знаете, как делается в финансовой отрасли (банки и т.п.)? Грубо говоря, существует три блока работ: а) аналитика в поле (исследование существующих систем); б) единое хранилище данных; в) бизнес-витрина (моделирование, бизнес-процессы, функции, аналитика). Аналитики области (а) проводят «археологические раскопки» и всё, что им удаётся обнаружить вводят в (б). Там найденные данные дополнительно систематизируются и структурируются (что само по себе может быть нетривиальной задачей). Затем бизнес-аналитики и архитекторы на основе извлечённых данных формируют инструменты для конечных пользователей -- область (в). Это довольно типовой и эффективный подход (у нас есть оч. сильные спецы). Могут быть и другие, конечно же.

                  • Марк Шварцблат Дмитрий
                    Рейтинг: 10
                    КТ "Акведук"
                    ИТ-директор
                    30.04.2013 12:58

                    1. Ну давай уже без Вы. Уши режет. :) 2. Процессы просто есть по факту. Ну не бывает так, что с нуля и сразу в средний бизнес. :) 3. Мы как раз исключение. Еще в начале двухтысячных начали ориентироваться на тонкие клиенты, частное облако (хотя так и не называли). 4. Как НАДО делать - понятно. Что банки себе могут позволить - тоже понятно. Но в подавляющем количестве средних организаций этим будет занимться 1-2 человека из ИТ. :)

                    • Дмитрий Капинос Марк
                      Рейтинг: 20
                      МГУ, Экономический факультет
                      Автор курсов, преподаватель
                      07.05.2013 18:36

                      1. 1.1. С маленькой буквы же, значит во множественном числе. Порядки вашей компании имею в виду. ) 1.2. Не могу не на "Вы", профессиональная деформация. Постоянно приходится общаться с огромным числом различных персон, разного статуса. Запоминать к кому на Вы, к кому на Ты -- голова лопнет. Вежливость и учтивость, опять же. ) Поэтому ко всем на Вы, даже к подчинённым и студентам. Но обычно без отчества. (Как англичане, те только к богу на ты. А мы только к товарищам, за обеденным столом, в дружеской обстановке). : ) 2. Я не про процессы как таковые (они-то всегда есть), а про их описания/модели/формализации. 3. Ну так замечательно же. Однако сегодня уже не исключение: все движутся к тонким клиентам. Я об этом. 4. 1-2 часто вполне достаточно для установившегося процесса. А вот компетенций только в ИТ может оказаться недостаточно. Впрочем, сейчас айтишники грамотные и если задачу поставить, подучатся, разберутся.

                      • Марк Шварцблат Дмитрий
                        Рейтинг: 10
                        КТ "Акведук"
                        ИТ-директор
                        08.05.2013 10:04

                        1. С профессиональными деформациями надо бороться. :) С кем общаешься часто - помнишь. Первый контакт - на Вы. Далее, если забыл, то уточняешь, даже и каждый раз. :) И все же в интернетах чаще всего "на ты", т.к. "you" уже за всё, а "thou" не используется. 2. Заметил, что грамотные специалисты как раз собираются в более узких, причем обслуживающих, областях - ИТ, кадры, маркетинг. В т.н. "продажниках" может быть всё, что угодно.

                        • Дмитрий Капинос Марк
                          Рейтинг: 20
                          МГУ, Экономический факультет
                          Автор курсов, преподаватель
                          22.05.2013 18:30

                          1. Да, надо как-то бороться. Может к психологу сходить, чтобы укольчик сделал. ) Или галстук снимать почаще... 2. Мне один товарищ (оппонент, кажется) рассказывал, что диссертаций по гуманитарным наукам защищается в разы больше, чем по точным (математика, технологии). Почему? Потому, что в точных "халтуру" можно легко вычислить, а в гуманитарных -- где много бла-бла, мнений и "йа-так-вижу" -- чётких критериев нет. Ну и нет гарантии от "чего угодно". Кто смел, тот и съел.

                          • Марк Шварцблат Дмитрий
                            Рейтинг: 10
                            КТ "Акведук"
                            ИТ-директор
                            22.05.2013 18:33

                            С точки зрения "гуманитарности" маркетинг как раз очень часто чрезмерно эмпиричен...

                            • Дмитрий Капинос Марк
                              Рейтинг: 20
                              МГУ, Экономический факультет
                              Автор курсов, преподаватель
                              23.05.2013 18:18

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

    • Дмитрий Капинос Марк
      Рейтинг: 20
      МГУ, Экономический факультет
      Автор курсов, преподаватель
      23.04.2013 19:32

      Да, корректное модельное описание реальности -- это труд живых людей. Как контролировать? Ну, примерно так же как работу финансистов, разработчиков, исследователей (вообще большая проблема, особенно чем ближе к фундаментальным исследованиям) и т.п. По хорошему, да, контролирующая служба должна разбираться в предметной области не худе подконтрольных, или звать аудитора со стороны. Или контролировать через результаты (через заранее определённые КПР, напр.). На счёт получения моделей: можно и нужно включить все существующие модельные наработки в состав архитектуры. СЭД в том числе. Его ведь уже проектировали, всё должно быть описано.

      • Марк Шварцблат Дмитрий
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        24.04.2013 16:18

        В общем - плохо все с контролем. И ключевые показатели далеко не у всех можно корректно определить. Только часто модели описаны сильно по-разному. Не стыкуются. Как-то раз паре особо настырных и сильно неглупых пользователей высокого уровня посвящения дал доступ к интерфейсу программирования процессов документооборота в портале. Смотрел. Плакал. .Люди пытались готовыми формальными блоками облегчить свою работы. Сами. В инициативном порядке. Они же участвовали в рабочих группах по всем процессам, включая СЭД для коммерческого блока. Я перестал удивляться - почему половина функций не востребована, а вторая половина работает не так, как надо. :)

        • Дмитрий Капинос Марк
          Рейтинг: 20
          МГУ, Экономический факультет
          Автор курсов, преподаватель
          29.04.2013 17:04

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

          • Марк Шварцблат Дмитрий
            Рейтинг: 10
            КТ "Акведук"
            ИТ-директор
            30.04.2013 11:17

            Плохо - это значит, что в предлагаемом алгоритме действий затраты на контроль чрезмерны получаются. Что-то не видел удачных попыток внедрить KPI для программистов в обычных средних коммерческих организациях. Равно как у проектировщиков и прочих дизайнеров. :) Дайте мне время и деньги и я решу любые проблемы, не противоречащие УК и законам природы. :)

            • Михаил Петров Марк
              Рейтинг: 264
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              30.04.2013 12:35

              Причем контроль должен быть, как сказано выше, очень высокопрофессиональный - и из-за этого еще более дорогой. KPI не помогут. Не работает.

            • Дмитрий Капинос Марк
              Рейтинг: 20
              МГУ, Экономический факультет
              Автор курсов, преподаватель
              30.04.2013 12:45

              «Что-то не видел удачных попыток внедрить KPI для программистов в обычных средних коммерческих организациях. Равно как у проектировщиков и прочих дизайнеров. :)» Да ладно Вам, кто-кто, а программисты и прочие дизайнеры прекрасно контролируются. Как раз, таки, по результатам. Делай, что хочешь, но в согласованный срок -- вынь, да положь. Особенно легко это делается в малых и крупных компаниях. Опыт имею. Причём был с обеих сторон. «Дайте мне время и деньги и я решу любые проблемы, не противоречащие УК и законам природы. :)» Профессиональный подход. А без денег? )

              • Марк Шварцблат Дмитрий
                Рейтинг: 10
                КТ "Акведук"
                ИТ-директор
                30.04.2013 13:02

                Если результат невозможно разложить на корпускулы с ежедневным количественным измерением, то это уже не KPI. Писатель может писать код полгода. Слишком долго ждать результата для оценки и контроля. А без денег - это хобби. и с этим куда-нить в Корпус Мира... :)

                • Дмитрий Капинос Марк
                  Рейтинг: 20
                  МГУ, Экономический факультет
                  Автор курсов, преподаватель
                  07.05.2013 18:48

                  KPI для того и придуманы, чтобы от пошагового контроля отойти. Чтобы за каждым рабочим не стоял надсмотрщик с плёткой. От контроля за за деятельностью перешли к контролю результатов. Для этого надо прежде всего договориться о мерах тех результатов. Это KPI и есть. Вот адекватно поставить их не разбираясь в предмете, да сложно бывает. Это кто это сейчас что по полгода пишет? В век объектно-ориентированного программирования и модульных архитектур. За полгода можно роман в стихах написать! Вы же сами приводили здесь ссылку на проект РЖД. Посмотрите, там проектировщики всё по косточкам для разработчиков разобрали, на несложные куски. Осталась практически рутинная и легкоизмеримая работа. С деньгами-то всякий сможет... )

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

                    Ну про "полгода" это Вы зря :) если система сложная и интегрированная - никакое ООП не поможет. А насчет проекта РЖД – не показали нам «нижнего» уровня декомпозиции. Как человек, которые делал подобные проекты, скажу что «дьявол прячется в деталях» как обычно, и пока детализированного уровня не увидел – нельзя сказать насколько такие документы в принципе пригодны для разработки системы.

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

                    Ну про "полгода" это Вы зря :) если система сложная и интегрированная - никакое ООП не поможет сделать ее за недели… у нас некоторые доработки делаются 1-3 месяца, а почему? Потому что «не навреди» и та самая архитектура – тут зацепишь – там аукнется. А насчет проекта РЖД – не показали нам «нижнего» уровня декомпозиции, просил – сослались на отсутствие разрешения. Как человек, которые делал подобные проекты, скажу что «дьявол прячется в деталях» как обычно, и пока детализированного уровня не увидел – нельзя сказать насколько такие документы в принципе пригодны для разработки системы. С деньгами не каждый сможет :(

                    • Дмитрий Капинос Михаил
                      Рейтинг: 20
                      МГУ, Экономический факультет
                      Автор курсов, преподаватель
                      22.05.2013 18:40

                      Ну, я к тому говорю, что если при проектировании задача разбита до достаточно дробных кусков и подзадач, то с выполнением и контролем такого выполнения проблем быть не должно. Трудно будет объяснить, напр., если кто-то, вдруг, не осилил несложный модуль, объект или функцию или N таких задач. По полгода же проекты длятся обычно потому, что таких элементарных задач оч. много. Часто можно было бы сократить сроки, умножив трудовые ресурсы, занятые на проекте. Но не всегда это экономически целесообразно. Про РЖД -- как там на самом деле не знаю, но подход из того, что выложили просматривается такой: разбили всё на элементарные работы при проектировании, а дальше воплощение их в код без надрыва.

                  • Марк Шварцблат Дмитрий
                    Рейтинг: 10
                    КТ "Акведук"
                    ИТ-директор
                    08.05.2013 10:08

                    Регулярное измерение результата != пошаговому контролю в общем случае. Даже и месяц - много. Я программистов контролирую либо по установленному при запуске задачи сроку, либо, если срок больше недели, то еженедельно. А без денег - это за идею и только в молодости. :)

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

                      На этапе непосредственно запуска иногда приходится и ежедневно статус собирать - особенно когда запуск "с колес". Соглашусь - в любом случае контролируется результат - не процесс. Процесс - нереально.

                      • Марк Шварцблат Михаил
                        Рейтинг: 10
                        КТ "Акведук"
                        ИТ-директор
                        08.05.2013 13:48

                        Но и KPI для непоточных действий чаще всего невозможен.

                        • Михаил Петров Марк
                          Рейтинг: 264
                          Счетная палата Российской Федерации
                          Директор департамента цифровой трансформации
                          08.05.2013 14:18

                          Соглашусь

  • Иван Чалей
    Рейтинг: 10
    ОАО "Сургутнефтегаз"
    Зам.нач-ка управления информационных технологий
    13.04.2013 10:46

    Прочитав сообщение Марка Рудольфовича, хочу заметить, что если есть информация об управлении ИТ-структурой в РЖД, но это не АП. Важнейшим отличием АП от методологий предыдущего слоя, является связь с бизнесом.И родоначальник этой дисскусси совершенно правильно подчеркнул, что это мостки между ИТ и бизнгесом. Управление ИТ структурой это чисто ИТ дела, а надо выстроить прозрачную систему отношения между бизнесои и ИТ. Хотелось бы чтобы, дискуссия шла в этом направлении. И конечно, АП - это свод правил, а их реализация, дело каждой организации, и здесь тоже инетересно услышать опыт коллег.

    • Михаил Петров Иван
      Рейтинг: 264
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      13.04.2013 12:34

      выстроить прозрачную систему отношения между бизнесои и ИТ. Хотелось бы чтобы, дискуссия шла в этом направлении - поддержу

    • Марк Шварцблат Иван
      Рейтинг: 10
      КТ "Акведук"
      ИТ-директор
      13.04.2013 12:56

      Как-то привычнее здесь на ты общаться. :) Управление ИТ-архитектурой ОАО «РЖД» Хм. ИТ-архитектура (ИТА) неотъемлемая часть общей архитектуры предприятия (АП). И разработка и сопровождения ИТА делается под бизнес-задачи, а не сферически в вакууме. Вообще связь с бизнесом должна быть чуть ли не на любом уровне, как мне кажется.

      • Иван Чалей Марк
        Рейтинг: 10
        ОАО "Сургутнефтегаз"
        Зам.нач-ка управления информационных технологий
        13.04.2013 13:37

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

        • Марк Шварцблат Иван
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          13.04.2013 14:23

          Сказали привет, посмотрели профиль == познакомились... :) Есть много разных видов деятельности, которые могут работать (всегда или какое-то время) без компьютеров. Не будет в них ИТ определять бизнес. Про RTE говорят и пишут чуть ли не 2000 года (когда там очередной модный пузырь доткомов лопнул?). А сами идеи реинкарнировали в начале 90-х из более ранних. И что? Очередной ярлычок Да почти про любой более-менее крупный бизнес можно сказать, что он живет в реальном времени. Посему все же считаю, что ИТ определяет (в значительной части) бизнес только там, где сам бизнес основан по большей части на ИТ-технологиях. К примеру, он-лайн торговля через Интернет.

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

            Про общение "на ты" на этой площадке поддержу кстати :) Относительно RTE. На мой взгляд, действительно не так много бизнесов, в который ИТ реально драйвит и определяет путь развития. Бизнес, связанный с массовым рынком, такой как он-лайн продажи - наверное да, так и есть. Есть бизнесы, в которых ИТ играет большую роль и которые без ИТ в современном мире просто практически невозможны - банки, энергетика... Но в них все-таки не ИТ определяет "лицо" бизнеса, ИТ просто инструмент, который делает его эффективнее.

            • Марк Шварцблат Михаил
              Рейтинг: 10
              КТ "Акведук"
              ИТ-директор
              18.04.2013 13:35

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

              • Дмитрий Капинос Марк
                Рейтинг: 20
                МГУ, Экономический факультет
                Автор курсов, преподаватель
                23.04.2013 20:29

                На случай ядерной войны, лучше на ферритовых сердечниках... )

                • Михаил Петров Дмитрий
                  Рейтинг: 264
                  Счетная палата Российской Федерации
                  Директор департамента цифровой трансформации
                  23.04.2013 20:54

                  У одного моего знакомого где-то лежит арифмометр Феликс...

                  • Дмитрий Капинос Михаил
                    Рейтинг: 20
                    МГУ, Экономический факультет
                    Автор курсов, преподаватель
                    23.04.2013 21:20

                    )) О, по нынешним временам это, наверно, уже раритет! Практичнее будет реализовать его до ядерной войны. )

                • Марк Шварцблат Дмитрий
                  Рейтинг: 10
                  КТ "Акведук"
                  ИТ-директор
                  24.04.2013 16:27

                  Если мне не изменяет склероз, то на них ЭМИ влияет ничуть не меньше. :)

                  • Дмитрий Капинос Марк
                    Рейтинг: 20
                    МГУ, Экономический факультет
                    Автор курсов, преподаватель
                    29.04.2013 17:08

                    Не исключено. ) Я просто помню из курса военной кафедры, что БЦВМ на боевых РН были на ферритовых сердечниках. )

                    • Марк Шварцблат Дмитрий
                      Рейтинг: 10
                      КТ "Акведук"
                      ИТ-директор
                      30.04.2013 11:22

                      Это было, вероятно, давно и оборудование было устаревшее или снятое с вооружения. :) Максимальная стойкость к ЭМИ у пневмо-компьютеров. :)

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

                        пневмо слишком громоздок для РН :)

                        • Марк Шварцблат Михаил
                          Рейтинг: 10
                          КТ "Акведук"
                          ИТ-директор
                          30.04.2013 12:49

                          Тю... У нас есть ТАКИЕ приборы... Но мы вам их не покажем... :)

                      • Дмитрий Капинос Марк
                        Рейтинг: 20
                        МГУ, Экономический факультет
                        Автор курсов, преподаватель
                        30.04.2013 12:50

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

                        • Марк Шварцблат Дмитрий
                          Рейтинг: 10
                          КТ "Акведук"
                          ИТ-директор
                          30.04.2013 13:06

                          Некоторое отношение имел к вопросу. Все же бортовые вычислители сейчас не аналоговые и на нормальной элементной базе, хотя и нашей разработки и производства. Ну не думаю, что к "Железному Феликсу" трудно будет ветряк приделать. :)

      • Дмитрий Капинос Марк
        Рейтинг: 20
        МГУ, Экономический факультет
        Автор курсов, преподаватель
        23.04.2013 19:37

        Шварцблат Марк Рудольфович: ИТ-архитектура (ИТА) неотъемлемая часть общей архитектуры предприятия (АП). И разработка и сопровождения ИТА делается под бизнес-задачи, а не сферически в вакууме. Вообще связь с бизнесом должна быть чуть ли не на любом уровне, как мне кажется. Должна. Поэтому постепенно и пришли от ИТ-архитектуры с зачаточными отсылками к бизнес-процессам и целям, к полноценной архитектуре предприятия и связному описанию. При этом есть тенденция понимать предприятие широко, включая сюда ещё и смежников.

        • Марк Шварцблат Дмитрий
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          24.04.2013 16:20

          Для смежников предпочитаю формализованные "шлюзы". :)

          • Дмитрий Капинос Марк
            Рейтинг: 20
            МГУ, Экономический факультет
            Автор курсов, преподаватель
            29.04.2013 17:09

            И правильно. ) Но одно другому не мешает, а даже наоборот.

            • Марк Шварцблат Дмитрий
              Рейтинг: 10
              КТ "Акведук"
              ИТ-директор
              30.04.2013 11:25

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

              • Михаил Петров Марк
                Рейтинг: 264
                Счетная палата Российской Федерации
                Директор департамента цифровой трансформации
                30.04.2013 12:37

                Вот наверное еще один критерий - так вкладываться на детальном уровне в архитектурные вопросы стоит скорее всего в условиях относительно стабильной среды. При быстрых изменениях будут "гири на ногах".

                • Марк Шварцблат Михаил
                  Рейтинг: 10
                  КТ "Акведук"
                  ИТ-директор
                  30.04.2013 12:50

                  В современном мире в любой стране любой бизнес меняется непрерывно и быстро. Иначе не выжить.

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

                    Не любой бизнес :)

                    • Марк Шварцблат Михаил
                      Рейтинг: 10
                      КТ "Акведук"
                      ИТ-директор
                      30.04.2013 14:37

                      Эээ... Какой бизнес не меняется? Примеры...

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

                        Не "не меняется", а "быстро не меняется" :) Государственный например - там все не быстро.

                        • Марк Шварцблат Михаил
                          Рейтинг: 10
                          КТ "Акведук"
                          ИТ-директор
                          30.04.2013 15:44

                          Что значит "государственный бизнес"? Сфера госуправления? Так там тоже НАДО БЫСТРО. Наша же чертова ДУМа с правительством никак не могут спать спокойно. Всё время генерируются изменения, дополнения. Или государственные унитарные имеешь в виду? Там тоже надо быстро. они-то живут в конкурентной среде.

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

                            Унитарные? В конкурентной? брось :) помимо этого - монополии. То что генерит Дума опосредованно на них влияет - не вызывают эти "толчки" каких-то свербыстрых и постоянных изменений в архитектуре

                            • Марк Шварцблат Михаил
                              Рейтинг: 10
                              КТ "Акведук"
                              ИТ-директор
                              30.04.2013 15:58

                              В конкурентной. Их осталось мало. Где у них эксклюзив остался? Монополии - это что? Газпром? РЖД? Они меняются. Вынужденно. Если вчера Дума приняла закон, что надо документы через одно окно со сроком позавчера - куда всем деваться?

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

                                Меняются конечно. Но скорость то явно не как в "рыночном" секторе.

                                • Марк Шварцблат Михаил
                                  Рейтинг: 10
                                  КТ "Акведук"
                                  ИТ-директор
                                  30.04.2013 16:38

                                  Да нормально. В среднем по больнице с учетом их масштабов. Думаешь у прочих больших быстрее? За аналогичную розницу, бытовую химию и металлообработку могу сказать, что тоже не спешно. :)

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

                                    Ну да, с учетом масштабов. Аналогичных Газпрому розниц не встречал :)

                  • Дмитрий Капинос Марк
                    Рейтинг: 20
                    МГУ, Экономический факультет
                    Автор курсов, преподаватель
                    07.05.2013 19:15

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

                    • Марк Шварцблат Дмитрий
                      Рейтинг: 10
                      КТ "Акведук"
                      ИТ-директор
                      08.05.2013 10:15

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

                • Дмитрий Капинос Михаил
                  Рейтинг: 20
                  МГУ, Экономический факультет
                  Автор курсов, преподаватель
                  07.05.2013 19:05

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

                  • Михаил Петров Дмитрий
                    Рейтинг: 264
                    Счетная палата Российской Федерации
                    Директор департамента цифровой трансформации
                    07.05.2013 20:48

                    Несомненно. Но я немного про другое. Чем изменчивее среда, чем быстрее изменения – тем больше «ручного управления» и тем больше «в голове», а не на бумаге, в моделях и т.п. Модели могут просто не успевать меняться, на их изменение может не хватить времени.

                    • Дмитрий Капинос Михаил
                      Рейтинг: 20
                      МГУ, Экономический факультет
                      Автор курсов, преподаватель
                      22.05.2013 18:59

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

              • Дмитрий Капинос Марк
                Рейтинг: 20
                МГУ, Экономический факультет
                Автор курсов, преподаватель
                30.04.2013 12:53

                Нет, это довольно мощная мировая тенденция. В рамках горизонтальной интеграции, напр. Есть и эталонные (референтные) модели, напр. Можно брать, подстраивать под себя и пользоваться.

                • Марк Шварцблат Дмитрий
                  Рейтинг: 10
                  КТ "Акведук"
                  ИТ-директор
                  30.04.2013 13:08

                  Ну ить. Понятно, что большую часть информации в любой деятельности мы откуда-то берем, перерабатываем и используем. Кстати. Исходные неадаптирванные под Россию модели очень плохо ложатся. Отметил это при получении бизнес-образования.

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

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

              • Дмитрий Капинос Марк
                Рейтинг: 20
                МГУ, Экономический факультет
                Автор курсов, преподаватель
                07.05.2013 18:55

                Тем не менее горизонтальная интеграция весьма распространённое явления, где-то экономящее огромное количество времени, где-то кучу денег. Есть эталонные (референтные) модели (чтобы велосипед не переизобретать).

                • Марк Шварцблат Дмитрий
                  Рейтинг: 10
                  КТ "Акведук"
                  ИТ-директор
                  08.05.2013 10:09

                  Интеграция чего? ПО???

                  • Михаил Петров Марк
                    Рейтинг: 264
                    Счетная палата Российской Федерации
                    Директор департамента цифровой трансформации
                    08.05.2013 13:25

                    И процессов тоже... Не вспомню навскидку, давно занимался темой - есть даже организация, которая поддерживает референтные отраслевые процессные модели, и утверждается, что за счет следования им легче налаживаются взаимодействия как внутри компании, так и с ее смежниками. Это я за что купил... :)

                    • Марк Шварцблат Михаил
                      Рейтинг: 10
                      КТ "Акведук"
                      ИТ-директор
                      08.05.2013 13:51

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

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

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

                        • Марк Шварцблат Михаил
                          Рейтинг: 10
                          КТ "Акведук"
                          ИТ-директор
                          08.05.2013 14:37

                          Как сотрудник группы, которая в основном занимается торговлей, я знаю много примеров, когда поставщик смотрит в программе покупателя (хотя чаще получает отчеты) и когда покупатель работает в системе поставщика. Но это не интеграция систем. Интеграция - это то, что сейчас раскручивают под брендом "управление цепочками поставок". Но это, в любом случае, ВЕРТИКАЛЬНАЯ интеграция. Расскажите мне про горизонтальную. :) P.S. Точнее так и это тоже интеграция, но не совсем та. В голову приходит система, когда продавцы-франчайзи работают в единой системе с материнской компанией. Это живой пример.

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

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

                            • Марк Шварцблат Михаил
                              Рейтинг: 10
                              КТ "Акведук"
                              ИТ-директор
                              08.05.2013 15:15

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

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

                                Понятно. Читал, что хозяйства на селе сбытовые такие структуры создают...

                                • Марк Шварцблат Михаил
                                  Рейтинг: 10
                                  КТ "Акведук"
                                  ИТ-директор
                                  08.05.2013 15:30

                                  Есть и сбытовые. И не только на селе. Но я все же не про создание отдельной орагнизации, а про интеграцию процессов. :)

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

                                    Поясни тогда что ты имеешь ввиду под "интеграцией процессов".

                                    • Марк Шварцблат Михаил
                                      Рейтинг: 10
                                      КТ "Акведук"
                                      ИТ-директор
                                      08.05.2013 16:25

                                      Тебе приходилось ли трудиться на заводе, имевшем территориально распределенные производства? Или в НИИ с удаленным опытным производством?

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

                                        Заводы - клиенты были такие когда я еще во внедренческом консалтинге работал. и? "ты не мудри, ты пальцем покажи" (народный фольклор)

                                        • Марк Шварцблат Михаил
                                          Рейтинг: 10
                                          КТ "Акведук"
                                          ИТ-директор
                                          08.05.2013 16:52

                                          Ну вот если вместо вынесенных подразделений представить отдельные организации, то это и будет интеграция процессов. Как мне кажется.

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

                                            хм... не проникся... ну да ладно, замнем :)

                          • Дмитрий Капинос Марк
                            Рейтинг: 20
                            МГУ, Экономический факультет
                            Автор курсов, преподаватель
                            22.05.2013 19:09

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

                  • Дмитрий Капинос Марк
                    Рейтинг: 20
                    МГУ, Экономический факультет
                    Автор курсов, преподаватель
                    22.05.2013 19:02

                    Ну и ПО в том числе. Почем нет?

              • Дмитрий Капинос Марк
                Рейтинг: 20
                МГУ, Экономический факультет
                Автор курсов, преподаватель
                07.05.2013 18:56

                Тем не менее горизонтальная интеграция весьма распространённое явления, где-то экономящее огромное количество времени, где-то кучу денег. Есть эталонные (референтные) модели (чтобы велосипед не переизобретать).

              • Дмитрий Капинос Марк
                Рейтинг: 20
                МГУ, Экономический факультет
                Автор курсов, преподаватель
                07.05.2013 18:59

                Тем не менее горизонтальная интеграция весьма распространённое явления, где-то экономящее огромное количество времени, где-то кучу денег. Есть эталонные (референтные) модели (чтобы велосипед не переизобретать).

      • Дмитрий Капинос Марк
        Рейтинг: 20
        МГУ, Экономический факультет
        Автор курсов, преподаватель
        23.04.2013 20:20

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

        • Михаил Петров Дмитрий
          Рейтинг: 264
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          23.04.2013 20:59

          В АП охват задач несколько иной - поясните?

          • Дмитрий Капинос Михаил
            Рейтинг: 20
            МГУ, Экономический факультет
            Автор курсов, преподаватель
            23.04.2013 21:28

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

            • Михаил Петров Дмитрий
              Рейтинг: 264
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              25.04.2013 09:49

              Очень сильно пересекается с ИТ-стратегией - ее drill down?

              • Дмитрий Капинос Михаил
                Рейтинг: 20
                МГУ, Экономический факультет
                Автор курсов, преподаватель
                29.04.2013 17:13

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

                • Михаил Петров Дмитрий
                  Рейтинг: 264
                  Счетная палата Российской Федерации
                  Директор департамента цифровой трансформации
                  29.04.2013 18:54

                  можно так адаптировать метод, что ИТ-стратегия станет в нём целью - поясните, пожалуйста

                  • Дмитрий Капинос Михаил
                    Рейтинг: 20
                    МГУ, Экономический факультет
                    Автор курсов, преподаватель
                    30.04.2013 13:03

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

                    • Михаил Петров Дмитрий
                      Рейтинг: 264
                      Счетная палата Российской Федерации
                      Директор департамента цифровой трансформации
                      30.04.2013 14:18

                      понял, спасибо. да, было бы интресно :)

        • Марк Шварцблат Дмитрий
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          24.04.2013 16:22

          Возможно. но пока в РЖД все далеко не айс. Начиная с бумажных списков предъявителей электронных билетов и заканчивая регулярными опозданиями. :)

          • Дмитрий Капинос Марк
            Рейтинг: 20
            МГУ, Экономический факультет
            Автор курсов, преподаватель
            29.04.2013 17:26

            Ну, Логика Бизнеса в этом скорее всего не виновата. )

            • Марк Шварцблат Дмитрий
              Рейтинг: 10
              КТ "Акведук"
              ИТ-директор
              30.04.2013 11:26

              Люди, проектировавшие систему, точно виноваты. :)

              • Михаил Петров Марк
                Рейтинг: 264
                Счетная палата Российской Федерации
                Директор департамента цифровой трансформации
                30.04.2013 12:38

                каждый бизнес достоин той системы, которую имеет...

                • Марк Шварцблат Михаил
                  Рейтинг: 10
                  КТ "Акведук"
                  ИТ-директор
                  30.04.2013 12:59

                  Сейчас часто бывает так, что Система имеет Бизнес. :)

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

                    да, по некоторым своим системам я такое вижу

                    • Марк Шварцблат Михаил
                      Рейтинг: 10
                      КТ "Акведук"
                      ИТ-директор
                      30.04.2013 14:39

                      :)

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

                        Да, такое бывает :) степень автоматизации процессов очень высокая :)

              • Дмитрий Капинос Марк
                Рейтинг: 20
                МГУ, Экономический факультет
                Автор курсов, преподаватель
                30.04.2013 13:07

                Скорее «не проектировавшие», потому что, как её когда-то спроектировали под требования своего времени, так никто и не модернизировал. Не инвестировали, сидели на том, что есть. Но, вот, мы видим, что потихоньку процесс пошёл уже. Хороший знак, я считаю.

                • Марк Шварцблат Дмитрий
                  Рейтинг: 10
                  КТ "Акведук"
                  ИТ-директор
                  30.04.2013 13:09

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

  • Дмитрий Капинос
    Рейтинг: 20
    МГУ, Экономический факультет
    Автор курсов, преподаватель
    23.04.2013 15:13

    Извиняюсь задержку с ответом. Моё личное видение по первому пункту: Что такое архитектура и зачем этим нужно заниматься Архитектура предприятия — не модная или маркетинговая концепция, а появилась и находит применение по вполне объективным причинам. Уже сейчас архитектурная функциональность рассматривается как полноценная функциональная область предприятия наравне с маркетингом, финансами, управлением персоналом и проч. Предприятие может рассматриваться как экономический инструмент — способ производительного сочетания ресурсов (факторов производства) — созданный для достижения определённых стратегических целей владельца. В случае предпринимателя-капиталиста это извлечение прибыли и увеличение капитала (что следует из самого определения капитала). Но принципиально цели могут быть и иными (социальными, напр.). Поскольку же капиталистические отношения на данный момент времени являются господствующими, говоря о стратегических целях и функциональных процессах в рамках предприятия, принято говорить о бизнесе. Но, понятно, что это в некоторой степени условность. Целый спектр технологий (в самом широком смысле), среди которых одно из первейших мест занимают информационные (ИТ) и с ними связанные технологии, применяется в рамках этого экономического инструмента для повышения его эффективности за счёт повышения качества сочетания ресурсов, оптимизации различных аспектов работы составных частей предприятия. Технологии (и ИТ, в частности), в свою очередь, являются технологическим инструментом по решению прикладных задач в рамках экономической деятельности. Таким образом, имеем последовательность. Сверху вниз: стратегические цели определяют используемый экономический инструмент (предприятие), который, в свою очередь, определяет используемый технологический инструментарий — технологии, в первую очередь ИТ. И в обратную сторону, снизу вверх: доступный пул технологий определяет спектр возможностей по формированию и поддержке экономического инструмента (эффективная комбинация может быть неочевидной, а нахождение таковой в большинстве случаев является сложной комбинаторной задачей, решаемой в рамках НИР, НИОКР, в рамках инновационного менеджмента и т. д. или через бенчмаркинг, напр.). Достигаемый на этой основе экономический потенциал предприятия, в свою очередь, определяет стратегические возможности (доступные стратегические цели, возможные стратегии, скорость приближения к заданным целям и т. д.). Проблема же заключается в том, что растёт масштаб решаемых экономических задач, сложность процессов и систем. Предприятие, производившее на заре капитализма, скажем, пряжу (одну из основных статей экспорта капиталистических стран того времени), совсем не одно и то же, что предприятие, создающее авиалайнеры (с высокотехнологичными филиалами в 100+ странах мира); буровая первооткрывателя-авантюриста совсем не одно и то же, что индустриальные комплексы охватывающие по полконтинента с логистическими цепями, простирающимися на полмира. Если капиталист эпохи зарождения кап. отношений мог без труда сочетать в одном лице различные экономические и функциональные роли, — быть и собственником, и предпринимателем, и управляющим, и технологом, и проч., — то возрастающая сложность процессов последующих лет вызвала прогрессирующее разделение труда, выделение новых функциональных областей, дифференциацию ролей и буквально физическую невозможность их совмещения (сложные процессы требуют от участника длительного процесса специальной подготовки, и даже при наличии таковой интенсивность и темп современных трудовых нагрузок не оставляют возможности для совмещения). Разделение труда позволяет совместными усилиями решать новые сложные задачи. Обратной стороной этого является отсутствие целостного понимания задач, процессов и инструментов. Возрастающая сложность делает такое понимание проблематичным сама по себе, что ещё больше осложняется узкопрофессиональной специализацией. Плюс к тому возникает проблема согласования и коммуникации по причине всё того же функционального разделения и специализации: маркетолог разговаривает на языке маркетинга, оперирует нечёткими рыночными и социальными категориями, ИТ-специалист говорит на техническом языке и оперирует категориями высокодетерминированных систем, а задачи им ставит менеджер, мыслящий в терминах высокой степени абстракции. Всё это приводит к тому, что применяемые инструменты становятся неуправляемыми, стихийными, что чревато самыми негативными последствиями вплоть до катастрофических (а с увеличением сложности и мощи систем растёт и разрушительная сила катастроф). Попытки же составить представление об управляемом объекте с узкопрофессиональных позиций переходят в плоскость споров на тему «что лучше: оранжевое или тёплое?» По этой причине в 19-м веке появился, а в 20-м набрал силу как научная дисциплина системный подход. В его рамках объекты исследуются как целостные системы, с разложением их на составные подсистемы, выявляются многообразные и разнородные связи и механизмы обеспечения целостности этих сложных систем. При таком подходе «оранжевое» и «тёплое» могут сочетаться и сопоставляться в рамках одной системы без каких-либо логических противоречий. Системный подход как наиболее общее методологическое направление (набор основополагающих принципов) конкретизируется и уточняется в ряде общенаучных и специально-научных концепций, а также в специальных методологических средствах прикладного характера (см., напр., системный анализ). Одной из таких конкретизаций в области системного описания предприятия, как экономического инструмента, и его подсистем является относительно молодой архитектурный подход. Как я уже говорил ранее, практически все определения архитектуры — в области описания архитектуры предприятия, ИТ-архитектуры и их составляющих — фактически содержат в своём составе определение системы, ну и вариации относительно неё. Существует множество стандартов и архитектурных методик, но суть архитектурного подхода проста: разбить сложную систему на совокупность подсистем, доступных для понимания и описания (если не каждым участником предприятия, то по крайней мере специалистами соответствующих функциональных областей), показать как эти подсистемы органически складываются или должны складываться в результирующую целевую систему. Поскольку архитектура — это по своей сути система, основные вариации при её определении в различных стандартах сводятся к следующим: сама система, её модель (гипермодель — по аналогии с гиперграфом: совокупность разнородных моделей объединённых разнородными же связями), манипуляции с двумя предыдущими (с самой системой и её моделью). Обобщая, можно утверждать, что архитектура — это замысел системы, который находит отражение в её существующей или будущей реализации. Нужно подчеркнуть, что архитектура не тождественна структуре, и не тождественна системе вообще. Структура, как и система, свойственна всем объектам живой и неживой природы, архитектура (как и замысел) только сколь-либо целенаправленно созданным человеком (артефактам). Объект именно в той мере обладает архитектурой, в какой он целенаправленно создавался человеком. У здания архитектура ярко выражена, напр., у кучи мусора её нет (если, конечно, это не т. н. художественное произведение). Каково практическое назначение архитектуры (зачем этим заниматься)? Архитектуры различных уровней строятся главным образом, чтобы обеспечить понимание сложного объекта управления. Такое понимание позволяет повысить как качество самого инструмента (увидеть его недостатки, недостаточность, избыточность и т. п.), так и качество его применения (усовершенствовать способы использования, повысить управляемость и проч.). Архитектура предприятия представляет собой стратегическое, нисходящее видение организации (предприятия), которое позволяет руководителям всех уровней, плановикам, проектировщикам, инженерам и др. участникам слажено координировать, объединять и осуществлять их деятельность. Задача архитектурной функции вырабатывать стратегический контекст для совместной и согласованной работы. Ещё одним немаловажным преимуществом архитектур является формализация и документирование достигнутого понимания, перевод имеющихся знаний о сложной системе из области неявного знания в область явного. Это позволяет повторно использовать эффективные практики (напр., оперативно «клонировать» организацию успешного подразделения на другие или на вновь создаваемые), смягчить зависимость предприятия от «незаменимых» сотрудников (когда знания о реальных процессах находятся в головах наёмных работников, мозаичны и теряются для предприятия с их уходом) и т. д. Разумеется, это не исчерпывающее перечисление выгод и результатов от использования архитектурного подхода (довольно подробное перечисление таких выгод можно найти, напр., в соотв. разделах различных архитектурных стандартов, но в рамках данной заметки не хотелось бы заниматься разбором, лучше потом остановиться на этом отдельно). Ну и в заключение можно остановиться на том, чем архитектура (в силу вышесказанного) не является. Архитектура — это не АСУ. Хотя архитектурные работы могут быть в известной степени автоматизированы (насколько это экономически целесообразно), а АСУ как ИС или комплекс могут включаться в состав архитектурных описаний. Архитектура не подменяет и не делает излишними ни стратегическое, ни операционное управление, ни управление ИТ. Это платформа для их эффективного взаимодействия, системообразующий элемент, ориентирующий всякую деятельность в рамках предприятия на стратегические ориентиры. В общих чертах так. Если дополнить картинками, то получается почти статья.

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

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

      • Дмитрий Капинос Михаил
        Рейтинг: 20
        МГУ, Экономический факультет
        Автор курсов, преподаватель
        23.04.2013 21:08

        Спасибо! ) Ссылок туда ещё добавить, на академические труды, и картинок на UML'е. )

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

          Не, UML гендиректор не поймет :)

          • Дмитрий Капинос Михаил
            Рейтинг: 20
            МГУ, Экономический факультет
            Автор курсов, преподаватель
            23.04.2013 21:46

            : ) Это смотря как оформить. )

    • Иван Чалей Дмитрий
      Рейтинг: 10
      ОАО "Сургутнефтегаз"
      Зам.нач-ка управления информационных технологий
      25.04.2013 10:59

      Классный и профессиональный материал, который в значительной мере объясняет кому нужна АП, или как сейчас принято говорить, кто спонсор - этого направления. С моей точки зрения, это заработает, если необходимость наличия инструмента типа АП поимет высшее руководство компании. В большинстве случаев, это может быть зам. герерального по финансам и по производственной деятельности (лучше эту должность назвать - главный инженер). А департамент ИТ - для него это рабочий инструмент, точнее подсказка, что и как делать. Коллеги, в большинстве комментариев отражается поверхостно обсуждаемый вопрос. Хотелось бы услышать мнение, какая из методологий кем-то применялась, вот мы, например, используем методологию TOGAF, модифицировали метамодель под свои задачи и понимание в развитиии ИТ хозяйства. Работаем над использованием Solution Manager как центрального звена для описания каталогов метамодели, а какие подходы имеются у коллег?

      • Дмитрий Капинос Иван
        Рейтинг: 20
        МГУ, Экономический факультет
        Автор курсов, преподаватель
        29.04.2013 15:36

        Иван Вацлавович, спасибо за оценку! «С моей точки зрения, это заработает, если необходимость наличия инструмента типа АП поимет высшее руководство компании. В большинстве случаев, это может быть зам. герерального по финансам и по производственной деятельности (лучше эту должность назвать - главный инженер). А департамент ИТ - для него это рабочий инструмент, точнее подсказка, что и как делать». Полностью согласен. На практике, инициаторами проектов по АП часто выступают неайтишные департаменты (менеджмента качества, напр., или инициатива напрямую исходит от топов). Или айтишные, если, к примеру, в компании принимаются требования обоснования и отчётности по инвестициям в ИТ. Тогда приходится увязывать деятельность ИТ-подразделения и её результаты с функциями, сервисами и целями бизнеса. Для успешного выполнения этой задачи необходимо обладать достаточными (зависит от задачи) компетенциями в обеих предметных областях (бизнес, ИТ), либо создавать смешанные команды, с включением в них специалистов разных департаментов. Участие и заинтересованность в архитектурных работах представителей топ-менеджмента, вообще, ключевой момент. Всякая устоявшаяся среда обладает инерцией и противится изменениям. Особенно, когда цели и смысл таких изменений участникам на местах не очень понятны. Что часто и происходит по ряду причин: та самая проф. ограниченность, корпоративная культура (когда отдельные исполнители, начиная с некоторого уровня управления, не видят картины в целом и не знают, на достижение какой конечной цели они работают) и др. По-хорошему, необходима разъяснительная работа, как с участниками архитектурного проекта, так и со всеми стейкхолдерами, кого, так или иначе, затрагивают архитектурные работы. Если же такая работа почему-либо невозможна, требуется авторитет топ-менеджера. Ещё хуже, когда сотрудники на местах вполне представляют, для чего проводятся работы, но тихо саботируют их по причине оппортунистического поведения (нежелание прилагать усилия, желание сохранить статус-кво и т.п.). Тут без воли и полномочий топ-менеджмента не обойтись. Чаще всего приходится сталкиваться с непониманием со стороны ИТ-специалистов, которых руководство обязало участвовать в архитектурных работах. Аргументы всегда примерно такие: - Это никому не надо. Бизнес-подразделения или CIO, инициировавшие проект, просто не понимают, что хотят. - Это не будет работать. Потому, что актуализация требует усилий, а делать это будет некому. А если есть кому, то нет желания и интереса. Ну и вариации на эти темы. По-моему, проблема здесь практически всегда лежит в организационной плоскости. Что, в общем-то, тоже архитектурная задача. «Коллеги, в большинстве комментариев отражается поверхостно обсуждаемый вопрос». Возможно, это следствие формата общения. Переписка в комментариях предполагает телеграммный стиль, ограниченность времени на ответ (между другими занятиями), плюс урезанная функциональность (отсутствие возможности размещать картинки, хотя бы с др. файлохранилищ, напр., – по-моему, весьма существенный минус). Тема же предполагает вдумчивое отношение, даже некоторый исследовательский энтузиазм. Это трудно уместить в короткие реплики. По моему мнению, для серьезного обмена мнениями наиболее подошли бы либо статьи, либо тематический клуб. К слову говоря, наши очаровательные пиарщицы напомнили, что ориентировочно 21-го мая планируется проведение круглого стола по теме «Управление архитектурой предприятия: организация согласованного управления бизнес- и ИТ-архитектурами. Рекомендации The Open Group (TOGAF)». Чуть позже должен быть официальный анонс. Пользуясь случаем, приглашаю Вас и других участников данной дискуссии принять участие в круглом столе. На данный момент предполагаются вводные доклады по следующим темам: - Резюме подходов в области управления архитектурой предприятия. - Методология The Open Group (TOGAF) для организации управления архитектурой предприятия. А также выступления экспертов из крупных компаний, имеющих опыт архитектурных проектов (вроде бы уже есть договорённости). Ну и, самое главное, свободное обсуждение вопросов, связанных с АП, обмен мнениями, идеями. Было бы очень здорово увидеть вас всех в качестве участников. «Хотелось бы услышать мнение, какая из методологий кем-то применялась, вот мы, например, используем методологию TOGAF, модифицировали метамодель под свои задачи и понимание в развитиии ИТ хозяйства. Работаем над использованием Solution Manager как центрального звена для описания каталогов метамодели, а какие подходы имеются у коллег?» Иван Вацлавович, а Вы сами не планируете изложить ваши результаты в виде статьи или доклада? Мне лично, очень было бы интересно ознакомиться с подробностями. (Если политика компании позволяет, конечно). Мы тоже стремимся придерживаться методологии TOGAF, адаптируя её под конкретные условия и задачи. Но вот моё знакомство с SAP весьма поверхностное, хотелось бы закрыть этот пробел (в части архитектурных работ). Что касается используемых программных инструментов в архитектурной области, то мой личный опыт ограничивается продуктами ARIS (Business Architect, IT Architect). Однако опыт компании богаче. Мне известно, что для различных задач у нас используются, напр., Alphabet planningIT, Oracle BPM, Oracle BI, ARIS PPM. По отдельным темам проводятся открытые онлайн-семинары – из первых рук, с последовательным описанием подхода (может кому будет интересно).

        • Михаил Петров Дмитрий
          Рейтинг: 264
          Счетная палата Российской Федерации
          Директор департамента цифровой трансформации
          29.04.2013 18:49

          ориентировочно 21-го мая планируется проведение круглого стола по теме «Управление архитектурой предприятия: организация согласованного управления бизнес- и ИТ-архитектурами. Рекомендации The Open Group (TOGAF)» - а в виде вебинара будет?

          • Дмитрий Капинос Михаил
            Рейтинг: 20
            МГУ, Экономический факультет
            Автор курсов, преподаватель
            30.04.2013 13:12

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

            • Михаил Петров Дмитрий
              Рейтинг: 264
              Счетная палата Российской Федерации
              Директор департамента цифровой трансформации
              30.04.2013 14:20

              да, было бы замечательно, спасибо

  • Михаил Петров
    Рейтинг: 264
    Счетная палата Российской Федерации
    Директор департамента цифровой трансформации
    29.04.2013 18:56

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

    • Дмитрий Капинос Михаил
      Рейтинг: 20
      МГУ, Экономический факультет
      Автор курсов, преподаватель
      30.04.2013 13:13

      Вам спасибо за участие! )

  • Илья Караваев
    Рейтинг: 10
    РДТЕХ
    Руководитель Практики ИТ-консалтинга
    13.05.2013 17:14

    День добрый! Обращаю внимание Сообщества и приглашаю всех желающих к участию в мероприятии 21 мая 2013 г. по теме: УПРАВЛЕНИЕ АРХИТЕКТУРОЙ ПРЕДПРИЯТИЯ. ОРГАНИЗАЦИЯ ЦЕЛОСТНОГО ОПИСАНИЯ И УПРАВЛЕНИЯ БИЗНЕС- И ИТ-АРХИТЕКТУРОЙ В СООТВЕТСТВИИ С РЕКОМЕНДАЦИЯМИ THE OPEN GROUP (TOGAF) Организаторы - компании РДТЕХ и Software AG. Семинар состоится с 10:30 до 14:30 в офисе компании РДТЕХ по адресу: Москва, ул. Нагатинская, д.1, стр.40, каб.212. Полный анонс мероприятия, программа и форма обязательной регистрации доступны по ссылке. Участие в семинаре бесплатное. Буду рад встретиться со всеми участниками дискуссии! С уважением, Караваев Илья

    • Михаил Петров Илья
      Рейтинг: 264
      Счетная палата Российской Федерации
      Директор департамента цифровой трансформации
      21.05.2013 00:17

      Добрый день! А запись будет? можете выложить где-нибудь?

      • Дмитрий Капинос Михаил
        Рейтинг: 20
        МГУ, Экономический факультет
        Автор курсов, преподаватель
        23.05.2013 18:12

        Вот здесь можно скачать презентации и посмотреть запись круглого стола (в части вебинара): http://rdtex.ru/win/root/event20130521.html (Моё выступление по TOGAF, к сожалению, получилось на троечку. По субъективным причинам. Опечален...)

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

          Спасибо!

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    31.05.2013 14:46

    How to Architect Customer Centric Organization The ultimate goal of customer centric organization is to architect an organization to bring value to customers in ways that are beneficial for them while also creating additional value for the company itself. What approach do you take to architect a customer centric organization?

    • Дмитрий Капинос Марк
      Рейтинг: 20
      МГУ, Экономический факультет
      Автор курсов, преподаватель
      03.06.2013 16:33

      Марк, твои комментарии? Мне больше всего нравится последний пункт, который: "People Perspective: Superior Customer Services are provided by dedicated Employees". А вообще, странно как-то -- англоязычный блог на российском домене... Почему, интересно.

      • Марк Шварцблат Дмитрий
        Рейтинг: 10
        КТ "Акведук"
        ИТ-директор
        03.06.2013 17:05

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

        • Дмитрий Капинос Марк
          Рейтинг: 20
          МГУ, Экономический факультет
          Автор курсов, преподаватель
          03.06.2013 17:58

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

          • Марк Шварцблат Дмитрий
            Рейтинг: 10
            КТ "Акведук"
            ИТ-директор
            05.06.2013 13:46

            Я все чаще задумываюсь над тем, что если рабочая среда, поддержка сотрудника и процессы организованы правильно, то сильно вкладываться в его учебу смысла нет.

            • Дмитрий Капинос Марк
              Рейтинг: 20
              МГУ, Экономический факультет
              Автор курсов, преподаватель
              07.06.2013 15:13

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

              • Марк Шварцблат Дмитрий
                Рейтинг: 10
                КТ "Акведук"
                ИТ-директор
                07.06.2013 15:43

                Спорить не буду. Но уверен, что соотношение 5 квалифицированных, мотивированных, отученных и облизанных на 95 простых исполнителей - более чем достаточно. :)

                • Михаил Петров Марк
                  Рейтинг: 264
                  Счетная палата Российской Федерации
                  Директор департамента цифровой трансформации
                  08.06.2013 03:05

                  а как же соотношение 20/80? :)

                  • Марк Шварцблат Михаил
                    Рейтинг: 10
                    КТ "Акведук"
                    ИТ-директор
                    08.06.2013 10:39

                    Не думаю, что в данном случает правило Вильфредо Парето применимо.

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

                      почему?

                      • Марк Шварцблат Михаил
                        Рейтинг: 10
                        КТ "Акведук"
                        ИТ-директор
                        13.06.2013 11:52

                        Ты считаешь, что в "нормальной" организации 20% сотрудников должны делать 80% работы? :)

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

                          Я нигде не говорил что должны :) У тебя не 20-80?

                          • Марк Шварцблат Михаил
                            Рейтинг: 10
                            КТ "Акведук"
                            ИТ-директор
                            17.06.2013 10:25

                            Вернемся к началу. Что 20 на 80? :)

                            • Дмитрий Капинос Марк
                              Рейтинг: 20
                              МГУ, Экономический факультет
                              Автор курсов, преподаватель
                              18.06.2013 16:21

                              Парето вывел это эмпирическое наблюдение (пропорцию), если память не изменяет, из статистики по распределению доходов в Италии позапрошлого века, что-то типа: 20 % семей Италии влащеют 80 % нац. богатства. Применительно к нашей ветке дискуссии можно заметить след.: 1) Если бы наш хитрый Вильфредо проводил своё исследование в наши дни, то пропорция скорее всего была бы ближе к 5/95, чем 20/80. 2) Формально говоря, работают-то, как раз 80 %, а 20 % "эффективные менеджеры". ) А вообще, 20/80 это не закон, а эмпирическое наблюдение, свидетельствующее просто о нелинейности распределения чего бы то ни было (наш мир, вообще, не оч. линеен, прямо скажем). Просто эти 20/80 так впечатлили всяких гуманитариев от экономики и менеджмента, что они стали активно "продавать" эту пропорцию как закон, де всё должно подчиняться именно такому распределению. А это не обязательно так. И если слепо этому следовать, то можно пострадать.

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

                                да вообще понятно, что за 20/80 зачастую просто стоит некий юмор :) а в каждой шутке есть доля шутки :)

                              • Марк Шварцблат Дмитрий
                                Рейтинг: 10
                                КТ "Акведук"
                                ИТ-директор
                                19.06.2013 12:06

                                ИМХО. Если ОСВОБОЖДЕННЫХ (без дополнительных обязанностей) менеджеров (не в понятиях "активный продажник", а управленец для группы людей или процессов) больше 10%, то в организации что-то неладно.

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

                              20% сотрудников делают 80 % результата и вообще это шутка не занудствуй :)

                              • Марк Шварцблат Михаил
                                Рейтинг: 10
                                КТ "Акведук"
                                ИТ-директор
                                19.06.2013 12:03

                                Разве что - шутка. При таком раскладе 70% сотрудников, вместе с их начальником надо гнать. :)

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

                                  тогда из оставшихся сотрудников 70% в скором времени перестанут работать, чтобы соблюсти пропорцию :) это, по-моему, один из законов Мерфи или Паркинсона... в общем - из той оперы :)

                                  • Марк Шварцблат Михаил
                                    Рейтинг: 10
                                    КТ "Акведук"
                                    ИТ-директор
                                    21.06.2013 15:03

                                    Нет. Если позволяешь кому-то из сотрудников не работать, то количество неработающих стремится к 100%. :)

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

                                      это точно :)

                • Дмитрий Капинос Марк
                  Рейтинг: 20
                  МГУ, Экономический факультет
                  Автор курсов, преподаватель
                  18.06.2013 16:13

                  Это уже не вопрос -- надо/не надо учить, а вопрос стратегии (кого учить). Введение института прорабов -- экономия (достаточность усилий), при параллельном снижении качества и повышении рисков. Понятно, что при прочих равных 100 % профи работу выполнят лучше, чем 5 % профи + 95 % низкоквалифицированных. Можно для чистоты эксперимента представить себе ситуацию из военной сферы: спецназ vs колхозники с парой служивых. Зависимость от 5 % -- это, помимо прочего, создание касты незаменимых (имеющих компетенции и знающих специфику данной работы здесь и сейчас), риск получить паралич (или чего похуже), если они уйдут/не смогут быть на рабочем месте/начнут саботировать и т.д. Могут быть далеко идущие последствия, и чем уже база профи, тем эти последствия вероятнее. Понятно, также, что 100 % спецов дороже, чем 5 %. Но, опять же, могут быть нюансы. Обычно 100 % персонала делят на кластеры по специализации, внутри которых стремятся иметь узких профи. В результате каждый профи в чём-то своём и все вместе покрывают потребность в необходимых компетенциях на 100 %. Незаменимых нет. Гоблинов с кривыми руками -- тоже нет. До поры до времени это работает. Но узкая компетенция, в общем-то, тоже зло.

                  • Марк Шварцблат Дмитрий
                    Рейтинг: 10
                    КТ "Акведук"
                    ИТ-директор
                    19.06.2013 12:17

                    Оговорюсь - я пишу про обычную коммерческую организацию. Не ИТ, не провайдер. Я всегда был противником старого коммунистического подхода к принижению роли личности в истории. УСПЕШНОСТЬ любого бизнеса всегда зависит от очень ограниченного круга людей. и как раз технических-то специалистов, будь то "сапёр", цискоид или мелкомягкий админ, найти проще и влияние их на результат меньше, чем хорошего коммерса с чуйкой. И да. Я не спорю, что узкая специализация - зло. Какое-то перекрытие функций должно быть. Иначе штаты начинают пухнуть хотя бы даже от необходимостей дежурств вечером и в выходные. И в любом случае - невозможно, даже при современных технических возможностях, НАПРЯМУЮ управлять несколькими десятками очень разнонаправленных сотрудников. В любом случае есть пирамидка управленцев. И в ней каждый узел также важен, как юникс-гуру в основании отдела системного администрирования. И даже важнее, т.к. передать на аусорс админку проще, чем управленческие функции.

                    • Дмитрий Капинос Марк
                      Рейтинг: 20
                      МГУ, Экономический факультет
                      Автор курсов, преподаватель
                      19.06.2013 23:22

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

                      • Марк Шварцблат Дмитрий
                        Рейтинг: 10
                        КТ "Акведук"
                        ИТ-директор
                        20.06.2013 11:19

                        Хм. Все же основной движущей силой признавалась энергия пролетарских масс во главе с авангардом в виде партии, а не отдельные наполеоны. :)

                        • Дмитрий Капинос Марк
                          Рейтинг: 20
                          МГУ, Экономический факультет
                          Автор курсов, преподаватель
                          02.07.2013 13:09

                          Не, они не могли не видеть, что массы организуют и ведут вожди и наполеоны. Но, говорили они, лидеры появляются не просто так, а подымаются на объективном движении этих масс. И без поддержки этих масс от лидера, как бы он хорош ни был, толку будет ноль. Грубо говоря, тот же комерс, какая бы у него чуйка ни была, что будет делать без годных цискоидов и админов. Я так это помню. В бизнесе, кстати, то же самое. Увидел тенденцию ("чуйка") -- можешь поднятся на ней (того же Джобса взять), даже если не оч.-то наполеон.

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    02.07.2013 16:29

    Садитесь, товарищ. Два. ;)

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

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

      в какой же оффтоп-то вас унесло от архитектуры, господа хорошие :)

      • Дмитрий Капинос Михаил
        Рейтинг: 20
        МГУ, Экономический факультет
        Автор курсов, преподаватель
        04.07.2013 19:05

        Сейчас Марк скажет, что господа в Париже... ; )

    • Дмитрий Капинос Марк
      Рейтинг: 20
      МГУ, Экономический факультет
      Автор курсов, преподаватель
      04.07.2013 19:00

      А ты весь параграф целиком читай. ) Я нагуглил источник. Там недвусмысленно сказано, куда все идут, если нет годных руководителей. К тому же эта цитата сказанному мной не противоречит. У меня по философии 5 было. )

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    03.07.2013 12:01

    Архитектура предприятия включает в себя кадровую структуру. Мы окружным путем подбираемся к роли ИТ-руководителей в развитии. :)

    • Дмитрий Капинос Марк
      Рейтинг: 20
      МГУ, Экономический факультет
      Автор курсов, преподаватель
      04.07.2013 19:04

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

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    05.07.2013 14:11

    Для Капиноса Д.Е. Известный классический источник. И не надо меня пугать пятерками. :) Я МЛФ дважды сдавал на пять и отдельно просто философию и историю философии. :) И все равно - коллектив первичен, а руководитель лишь верхушка айсберга (как Джобс). Без команды (массы соратников) условный наполеон в нашем деле ничего сделать не сможет.

    • Дмитрий Капинос Марк
      Рейтинг: 20
      МГУ, Экономический факультет
      Автор курсов, преподаватель
      15.07.2013 19:19

      Так я против источника ничего не имею. ) "И не надо меня пугать пятерками. :) Я МЛФ дважды сдавал на пять и отдельно просто философию и историю философии. :)" Боюсь!1 ) --- Руководитель и коллектив -- тут связь скорее всего "диалектическая", по отдельности не шибко продуктивны.

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    14.08.2013 10:21

    Seven Aspects of Business Architecture

    Enterprise Architecture is a synthesis of the Enterprise Business Architecture and Enterprise IT Architecture disciplines. BA should provide the business context for EA

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    08.10.2013 12:56

    The Value of IT Architecture

    "The Master does nothing, yet he leaves nothing undone." - The Tao of Architecture

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    11.10.2013 10:03

    What about the Enterprise Architects?

    Enterprise architects should not be looking at how they can design and dictate global, universal frameworks, but should use their deep technical knowledge and ability to abstract to patch some of the biggest gaps in the services lifecycle for most companies.
    iStock_000005614684XSmall.jpg

Предметная область
Отрасль
Управление