Архитектор – строит, а что делает аналитик?

14.10.20

Анализ и управление - Анализ и проектирование ИТ-систем

Как только вспоминаешь проект по внедрению, особенно тот, что средний и выше (а в уме мы держим, что это проект 1С), то тут же видишь кучу народа, и каждый что-то делает. И вот тут вопрос – кто и что делает на проекте?

Пара вводных слов

Сразу сделаю несколько пояснений:

  • Речь в этой статье только об области знаний и поле деятельности 1С. Т.е. если написано, «Специалист технической поддержки», то подразумевается, что это техническая поддержка 1С, а не поддержка приема и учета жалоб локального ЖКХ.
  • В статье говорится о внедрении 1С на средних и крупных проектах. Данные рассуждения для малых компаний с запросом – «нам в бухгалтерии нужен вот такой отчетик» – не подходят.
  • Рассматриваем только особенности применения архитектуры предприятия и ИТ-архитектуры на практике, и в рамках проектов внедрения ИТ. Более широкие вопросы, например, по трансформации бизнеса и изменений финансовых показателей и др. – не рассматриваем.

Часть 1. Попытка разложить все по полочкам

Об «архитектуре» пишут много, пишут часто, пишут вкусно, становятся экспертами, передают экспертный опыт, а еще бывают книги, тренинги, курсы, консалтинги, консорциумы, институты с обязательной вставкой EA (Enterprise Architecture) – IFEAD, iEAi, международные стандарты – ISO 15704, 42010 и др., и, да, можно говорить, писать долго и не по делу. А дело есть и вполне конкретное, и даже два:

  • Вопросы, что такое «Архитектура», «Предприятие» и они вместе «Архитектура предприятия» остаются на повестке дня. И кто всем этим заведует?
  • И, как 1С с этим сосуществует и интегрируется ли? 

Если начать вникать, то методик, моделей, фреймворков – много, например, все что оканчивается на AF (Architecture Framework) – TOGAF, FEAF, TEAF, DoDAF и т.п.

Однако, когда стоит цель – провести автоматизацию или модернизировать существующие процессы, то волей-неволей приходится сталкиваться с этими понятиями – «Архитектура предприятия» и «Информационная архитектура». И иметь четкое представление, что это и как с этим работать. Сейчас просто вспомним для общего понимания картины.

Погружаясь в эти понятия, можно заметить такое разделение:

  • В иностранной литературе в понятие «ИТ-архитектура» входит понятие «Бизнес-архитектура». Одно следует из другого. Это наследие Дж. Захмана (J.A. Zachman). Он является родоначальником большинства известных описаний структур и именно он стал использовать их для описание ИТ-архитектуры. И со временем, скажем любимую фразу – исторически так сложилось, что понятие «Архитектура информационных систем» стало подменяться понятием «Архитектура предприятия». И произошло то, что сейчас, при описании чистой архитектуры предприятия, используются совсем не относящиеся к ней ИТ-термины.
  • В отечественном понимании эти понятия раздельные. При этом понятие «Архитектура предприятия» практически всегда приравнивается к понятию «Организационная структура» или «Корпоративная архитектура». А понятие «ИТ-архитектура» приравнивается к понятию «Архитектура программного обеспечения».

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

Определения – это не объяснения, но попробуем разобраться во всем этом. Если взять хотя бы понятие «Архитектура», то их можно уже насчитать несколько и это, не используя какое-либо слово-приставку к нему. Поэтому данная статья не пытается дать точное определение (а такого может и не быть), а лишь обозначить приемлемый вектор понимания используемого понятия.

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

Архитектура – это описание модели, общих элементов, взаимосвязей, конструкций, описание каркаса, скелета.

Но нам нужно понять, что будет тогда архитектурой предприятия.

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

Теперь соединим эти два понятия «Архитектура» и «Предприятие». Получаем.

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

При определении «Предприятия» и «Архитектуры предприятия» фигурирует такое понятие как «Система».

Система – это совокупность элементов, находящихся в отношениях и связях друг с другом, которая образует определенную целостность.

Архитектура системы – это принципиальная организация системы, воплощенная в ее элементах, их взаимоотношениях друг с другом и со средой, а также принципы, направляющие ее проектирование и эволюцию.

Наравне с BABOK (Business Analysis Body of Knowledge) – сводом знаний по бизнес-анализу и CBOK (Business Process Management Common Body of Knowledge) – сводом знаний по управлению бизнес-процессами, существует и BIZBOK (Business Architecture Body of Knowledge) – свод знаний, охватывающий основные области бизнес-архитектуры организации и сопутствующие практики.

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

Бизнес-архитектура (Business Architecture, BA или Enterprise Business Architecture, ЕВА) – это чертеж организации, который отображает полную картину организации и используется для синхронизации стратегических целей и тактических потребностей.

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

Традиционно ИТ-архитектуру предприятия представляют в виде нескольких взаимосвязанных компонентов:

  • Информационная архитектура (Enterprise Information Architecture, EIA) – набор методик и инструментов, описывающий информационную модель предприятия.
  • Архитектура прикладных решений (Enterprise Solution Architecture, ESA) – представляет архитектуру приложений, включающую в себя совокупность программных продуктов и интерфейсов между ними. В ней выделяют архитектуру программного обеспечения (Software Architecture) – совокупность важнейших решений об организации программной системы, которая может быть описана с помощью фреймворков (Software Architecture Frameworks): 4+1, RM-ODP (Reference Model of Open Distributed Processing), Service-Oriented Modeling Framework (SOMF).
  • Техническая архитектура (Enterprise Technical Architecture, ETA) – совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений.

Архитектура информационных систем предприятия основывается на двух идеологических определениях:

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

Возвращаясь к определению архитектуры предприятия, можно выделить два подвида:

  • Текущая архитектура (Current Architecture) описывает существующее состояние архитектуры предприятия, ее объективной реальности. Называется также архитектурой «Как есть» / AS IS, или базовым состоянием существующей архитектуры.
  • Целевая архитектура (Target Architecture) описывает будущее желаемое состояние (модель) предприятия или то, «Как будет» / TO BE.

Говоря об архитектуре предприятия и особенно в момент ее развития или реинжиниринга требуется знать, как понятие «Стратегия бизнеса» («Бизнес-стратегия»), так понятие «ИТ-стратегия».

Бизнес-стратегия – это направления развития фирмы в соответствии с поставленными стратегическими целями и задачами. Она отвечает на вопрос – почему фирма должна развиваться именно так и в этом направлении. Бизнес-стратегия включает:

  • цели и задачи, стоящие перед предприятием;
  • бизнес-решения, необходимые для достижения поставленных целей и задач;
  • изменения, которые нужно провести для достижения поставленных целей и задач.

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

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

Часть 2. Нужны ли эти все люди и как их называть?

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

Есть два мнения и каждое имеет право на существование. Особенно, если оно аргументировано минимум тремя пунктами.

  1. «Как корабль назовешь, так он и поплывет» (С) Капитан Врунгель

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

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

  1. «Кадры решают все» (С) Сталин И.В.

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

А к чему эти два описанных выше момента, а к тому, что вспомним проект внедрения любой 1С. В команде будут: менеджер проекта, руководитель проекта, архитектор, аналитик, программист/ы, консультанты и еще много кого. И мы говорим о команде только со стороны исполнителей. А теперь подробнее:

  • Менеджер проекта. Тут вроде все очевидно. Это такой человек, кто готовит документы – акты, накладные, смотрит сколько часов потрачено, выставляет счета. Присутствует на первой установочной встрече. Грубо говоря, ведет бумажную официальную работу между Клиентом и Исполнителем.
  • Руководитель проекта. Вот тут уже становится интереснее. В общих и главных чертах руководитель проекта – это лицо, которое несет ответственность за проект. Или, иначе руководитель проекта (Project Manager, PM) – лицо, наделенное ответственностью и правами по руководству работами в рамках проектной задачи. А теперь внимательно посмотрим на его английское название и вот тут встречаем путаницу, так как Руководителя проекта частенько называют и приравнивают к Менеджеру проекта. А это совсем не так. Детально не будем останавливаться, но вкратце обозначим обязанности Руководителя проектов:
    • Определение устава, целей, задач и результата проекта.
    • Составление и подготовка плана внедрения нового проекта, определение контрольных точек.
    • Определение количества ресурсов, требуемых для выполнения проекта.
    • Определение стоимости и бюджета проекта.
    • Выбор команды проекта и определение ролей и обязанностей в проекте для всех членов команды проекта.
    • Мониторинг хода исполнения проекта, прогнозирование отклонений и принятие своевременных мер по их устранению.
    • Организация и проведение совещаний команды проекта, а также координация коммуникаций между всеми участниками проекта и его заинтересованными сторонами.
    • Решение проблем, возникающих на проекте. Как тех, которые исходят от команды проекта, так и тех, которые могут возникают при управлении заинтересованными сторонами проекта.
    • Проведение анализа эффективности этапов проекта и проведение послепроектного анализа.
  • Архитектор. Его можно определить, как специалиста, организующего процесс разработки всех разделов проектной документации. Его основная цель – обеспечение решения задач бизнеса при помощи информационных технологий. В зависимости от масштаба проекта и понимание сущности проекта исполнителем, архитектор может быть далеко не один, и уже называться – бизнес-архитектором, функциональным архитектором, системным архитектором, техническим архитектором. Обобщенные ключевые обязанности:
    • Проектирование системы на основе требований заказчика;
    • Определение архитектуры системы;
    • Выбор технологии реализации поставленных задач;
    • Создание прототипа системы;
    • Обзор бизнес-требований;
    • Обзор и анализ кода больших изменениях;
    • Документирование всех архитектурных решений, постоянное обновление документации.
  • Аналитик. Как правило, это специалист, занимающийся изучением и обобщением различного рода информации по заданной цели, владеем методами анализа и моделирования процессов. В целом тут может быть зеркальная позиция с архитектором. Они могут и по-хорошему должны работать в паре. Отсюда можно выделить аналитика бизнес-процессов, функционального аналитика, системного аналитика, технического аналитика. Обязанности аналитика на проекте:
    • Выявление, сбор, анализ и описание требований;
    • Взаимодействие с заказчиками и экспертами предметных областей;
    • Анализ состояния бизнес-процессов «Как есть» / AS IS и моделирование их состояния «Как надо» / TO BE;
    • Консультации по выбору и внедрению информационной системы, обеспечивающей оптимальное решение выявленных задач;
    • Контроль реализации требований на всех этапах проекта;
    • Разработка технических заданий и постановка задач на разработку.
  • Консультант. Как правило на его долю выпадает постпроектное сопровождение или сопровождение на этапе промышленной эксплуатации. Т.е. его можно определить как специалиста, консультирующего пользователей по определенной предметной области и определенному кругу пользовательский вопросов, связанных с отражением хозяйственных операций в программе. Однако, могут встретиться еще две задачи, возникающие перед консультантами: вопросы по постановке учета в программах и формирование заданий программистам на разработку. Считать эти задачи задачами консультанта – не совсем корректно, особенно при наличии других ролей на проекте, например, архитектора и аналитика. Поэтому ключевая задача консультанта – доступно преподносить информацию разного уровня сложности и помогать разбираться в работе программы пользователям, возможно это совмещать с элементами обучения.
  • Программист. Программист выстраивает программный алгоритм (пишет код) – это его основная задача. Тут все четко и понятно.
  • Все остальные:
    • Тестировщик – иногда эту роль / функцию относят на уровень аналитиков, консультантов, ну и в самом крайнем случае – пользователей. Хорошо, данного специалиста может и не быть на проекте, если есть используется атематическое тестирование по кейсам.
    • Технический писатель – это специалист, который занимается составлением документации в рамках разработки различных программ и автоматизированных систем. К составляемым документам относятся задания для специалистов, руководство по эксплуатации для пользователей и многие другие.
    • UX-дизайнер (User Experience Designer) – это проектировщик, который изучает потребности пользователей, строит логические схемы работы интерфейса, тестирует прототипы на целевой аудитории и составляет техническое задание для UI-дизайнера.
    • UI-дизайнер (User Interface Designer) – дизайнер интерфейсов, который визуализирует рабочий прототип, отрисовывает кнопки, иконки, формы и другие его компоненты и собирает их в гармоничный работающий макет.
    • Специалист по информационной безопасности – принимают непосредственное участие в создании системы защиты информации, ее аудите и мониторинге, анализируют информационные риски, разрабатывают и внедряют мероприятия по их предотвращению.
    • Системный администратор – это специалист по обслуживанию компьютеров и локальных компьютерных сетей.
    • Администратор баз данных – это специалист, обслуживающий базы данных, как правило серверные базы данных, в которых информация собрана с разных компьютеров и может читаться на каждом из них.

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

А теперь накладываем все это на рассмотренные выше понятия «Архитектура предприятия» и «ИТ-архитектура», и получаем нужную картину. С этими двумя понятиями тесно работают два специалиста: архитектор и аналитик. Рассмотрим, какой архитектор и какой аналитик отвечает за какие области и решает какие задачи.

  • Бизнес-архитектор / Бизнес-аналитик

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

Основные результаты их деятельности:

    • Карта бизнес-процессов «Как есть» / AS IS;
    • Перечень бизнес требований;
    • Карта бизнес-процессов «Как будет» / TO BE;
    • ИТ-ландшафт «Как есть» / AS IS;
    • Дорожная карта изменений (переход от AS IS к TO BE).

Дорожная карта изменений содержит в себе мероприятия нескольких типов:

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

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

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

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

  • Функциональный архитектор / Функциональный аналитик

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

Основные первичные данные, с которыми происходит работа:

    • ИТ-ландшафт «Как есть» / AS IS;
    • Карта бизнес-процессов «Как будет» / TO BE;
    • Перечень функциональных требований.

Основные результаты их деятельности:

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

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

Основные первичные данные, с которыми происходит работа:

    • Перечень бизнес требований;
    • ИТ-ландшафт «Как есть» / AS IS;
    • Карта бизнес-процессов «Как будет» / TO BE;
    • Требуемые изменение (т.е. автоматизируемая функция, или процесс, или учет в соответствии с дорожной картой изменений).

Основные результаты их деятельности:

    • ИТ-ландшафт «Как будет» / TO BE;
    • Карта бизнес-процессов «Как будет» / TO BE в понятиях целевой архитектуры, т.е. с учетом ограничений внедряемых продуктов;
    • Перечень функциональных требований;
    • Техническое задание на систему.

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

  • Технический архитектор / Технический аналитик

Заключительное звено в цепочке разработки – это работа технического архитектора и технического аналитика. Они на основе данных трех предшественников формируют задания на разработку программистам. В основе своей работы они использую данные о платформе. Исходные данные для их работы: ИТ-ландшафт в модели «Как есть» / AS IS, карта бизнес-процессов «Как будет» / TO BE, сценарий работы с системой и перечень функциональных разрывов. Они ответственные за написание технических заданий и реализацию внесения изменений. Осуществляют контроль за исполнением технических заданий.

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

 

За некоторые интересные мысли благодарю Дениса Галимова – руководителя Отдела экспертизы ПервогоБИТа.

Проект архитектура предприятие архитектор аналитик команда ИТ-архитектура бизнес-архитектура стратегия

См. также

Анализ & Управление в ИТ-проектах, 30 мая - 1 июня 2024 г., Санкт-Петербург

Анализ и управление Управление проектом Анализ и проектирование ИТ-систем Мероприятия Россия Платные (руб)

Практическая конференция для аналитиков и руководителей проектов 1С. 30 мая - 1 июня 2024 г. Санкт-Петербург, отель Park Inn by Radisson Pribaltiyskaya, ул. Кораблестроителей 14

30000 руб.

27.05.2023    15632    1    0    

5

Code, LowCode, ChatGPT и 1C (9.0)

Мессенджеры и боты Анализ и проектирование ИТ-систем Бесплатно (free)

Разбираем, чего не хватает в 1С для того, чтобы "захватить мир", фантазируем на тему, что бы хотелось видеть в 1С 9.0, анализируем, как эти вопросы решают конкуренты, и - самое главное - примеры текущих решений.

29.08.2023    5652    comol    44    

40

5 подходов при доработке конфигурации 1С, чтобы в будущем не было мучительно больно её обновлять

Анализ и проектирование ИТ-систем Рефакторинг и качество кода Обновление 1С Платформа 1С v8.3 Бесплатно (free)

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

10.08.2023    7365    1c-izhtc    36    

16

Искусство отчета

Анализ и проектирование ИТ-систем Платформа 1С v8.3 Система компоновки данных Бесплатно (free)

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

26.02.2023    2541    DemetrKlim    38    

25

Принцип "Супермаркета" в управлении производством сложных узлов

Производство готовой продукции (работ, услуг) Бюджетирование и планирование Анализ и проектирование ИТ-систем Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Бесплатно (free)

Решение для планирования производства сложных узлов с формированием партий производства готовой продукции, исходя из свободных остатков основного материала в партиях поступления от поставщиков.

01.02.2023    1611    Soliton    0    

19

Подбор характеристик номенклатуры по сопоставлению свойств при запуске производства в 1С: ERP

Анализ и проектирование ИТ-систем Платформа 1С v8.3 1С:ERP Управление предприятием 2 Россия Управленческий учет Бесплатно (free)

В конкуренции выигрывает тот, кто сможет лучше удовлетворить запросы заказчиков. Многие современные производственные предприятия адаптируют своё предложение под запросы клиентов и вынуждены увеличивать многообразие вариантов готовой продукции за счёт расширения разнообразия её характеристик. Такой подход предполагает рост многообразия вариантов номенклатуры производимой готовой продукции, полуфабрикатов и закупаемых материалов. Объём информации, которую необходимо учитывать при планировании и контроле, увеличивается с большой скоростью. При этом не всегда свойства материалов, полуфабрикатов и готовой продукции имеют строгое соответствие, позволяющее использовать типовой функционал корпоративных систем на платформе 1С: ERP для автоматизации подбора номенклатуры. Что в итоге может существенно затруднять управление производством.

25.01.2023    2067    Soliton    4    

15

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Анализ и проектирование ИТ-систем Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    11411    Evil Beaver    17    

107
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. TODD22 18 14.10.20 13:13 Сейчас в теме
Архитектор – строит

Архитектор проектирует.
DarkAn; FatPanzer; +2 Ответить
2. FatPanzer 14.10.20 13:17 Сейчас в теме
(1) И осуществляет архитектурный контроль строительства...
3. TODD22 18 14.10.20 13:21 Сейчас в теме
(2)Да в том числе и "авторский надзор" :)
4. FatPanzer 14.10.20 13:22 Сейчас в теме
В итоге, на практике при внедрении программ системы 1С или, если более витиевато – при автоматизации бизнес-процессов Заказчиков, можно с большей вероятностью встретить аналитика, реже архитектора, логического разграничения внутри этих должностей как правило нет.
Вот она - одна из главных бед всех проектов...
5. user856012 13 14.10.20 13:22 Сейчас в теме
что делает аналитик?
По аналогии с определением кинокритика: бизнес-аналитик объясняет вам (за ваши деньги), как бы он вел ваш бизнес... если бы умел.
EVKash; XAKEP; user1464234; TODD22; +4 Ответить
8. XAKEP 14.10.20 13:42 Сейчас в теме
(5)
если бы умел :)


плюс
user1465005; stepan_s; +2 Ответить
6. TODD22 18 14.10.20 13:24 Сейчас в теме
В итоге, на практике при внедрении программ системы 1С или, если более витиевато – при автоматизации бизнес-процессов Заказчиков, можно с большей вероятностью встретить аналитика, реже архитектора, логического разграничения внутри этих должностей как правило нет.

Самая высокая вероятность в живой природе встретить "Тыж программиста", а не вот этих аналитиков, архитекторов....
7. FatPanzer 14.10.20 13:26 Сейчас в теме
(6) Ага.
— Самуил Маркович, Вы сильный, Вы справитесь!
— Яша, я — умный, я даже не возьмусь!
muskul; XAKEP; +2 Ответить
9. cherepaha-big 21.10.20 12:57 Сейчас в теме
(6) в живой природе на маленьком проекте - да, возможно. В большом проекте тыжпрограммист не потянет. Не думаю, что автоматизацию КАМАЗа, например, доверили бы тыжпрограммисту)))
10. TODD22 18 21.10.20 13:04 Сейчас в теме
(9)
доверили бы тыжпрограммисту)))

доверили бы тыжпрограммистам
11. Terve!R 06.11.20 15:39 Сейчас в теме
(9) заказчик не понимает как должно быть, ему нужен результат, а путь подрядчика к результату не особо волнует. Не все могут оценивать риски, и тем более понимать, что над программистом Васей должен стоять руководитель и аналитик. И вообще кто такой Вася - тыжпрограммист или руководитель проекта с командой. Кстати, цена вопроса может быть одинаковой)
Оставьте свое сообщение