Здравствуйте, дорогие друзья. Мы начинаем системную разработку под названием «Инженер — менеджер настоящего, системный архитектор будущего». Для кого эта системная разработка? Кто может ею воспользоваться? Ну, во-первых, слушатели программы Coursera. Они прошли курсы и теперь планируют закрепить эти курсы в выпускной дипломной работе. Поэтому это для слушателей программы Coursera. Но не только для них. Еще это для специалистов, для инженеров, для менеджеров реальных действующих компаний. Они могут взять шаблоны, прототипы, решения этого проекта за основу и с использованием этих шаблонов начинать решать свои предметные задачи. На своем предприятии, в своей сфере деятельности. Поэтому это для тех, кто учится, и для тех, кто работает. Отлично. Начинаем. Несколько полезных советов. Сначала хорошая новость. Утреннюю зарядку по ходу исполнения системного проекта можно не исключать и продолжать делать. Это новость один. Ну а дальше тоже неплохие рабочие новости. В проекте действуем прагматично и оптимистично. Не перегружаемся, не тонем в деталях, доходим до результата. В границах проекта системной разработки целесообразно одновременно включить и некоторый продукт, предмет рассмотрения, и связанные с этим продуктом системы деятельности. 2.0 — это и продукты, и системы деятельности, связанные с этими продуктами. Выбирая продукт и систему деятельности, которую вы будете рассматривать, разрабатывать, проектировать, анализировать, полезно принести себе пользу. Это польза может быть немедленная, сегодня, например, получить желаемые оценки и сертификаты, а также это может быть польза сегодня и завтра, если вы будете использовать полученные результаты для достижения успеха в своей деятельности. Еще полезные советы. В ходе системной разработки разделяем настоящее и будущее: как есть и как надо, то есть, работая в проекте системной разработки, каждый раз мы понимаем, в каком времени мы моделируем сегодня или на завтра. Развиваем решение по шагам. С первого раза не получается, поэтому не боимся действовать итерационно, не боимся дополнять, не боимся переделывать. Но каждый раз, закрывая работу над разработкой, необходимо довести представление решения до состояния, которое называется состоянием промежуточной готовности. То есть завтра это решение можно сразу продолжать или применять, то есть передвигаемся короткими шагами, но на выходе каждого шага имеем некий промежуточный оформленный результат. Гордимся полученными результатами. Показываем эти результаты, где надо, когда надо и кому надо. Ну и хорошая идея в заключение. Всем нам приходится много концептуально проектировать. Мы можем это сознавать или не осознавать, но идеи, концепции, проекты того, что мы хотим сделать в будущем, постоянно у нас возникают, поэтому вот это задание, эта работа, эта системная разработка — хороший повод потренироваться в концептуальном быстром проектировании сложных высокотехнологичных продуктов и сложных систем деятельности, которые имеют дело с этими сложными продуктами. То есть потренироваться в проектировании будущего, анализе настоящего и улучшении настоящего. План системной разработки. Сначала задаем объект системного инжиниринга, предмет нашей разработки, Дальше по правилам системного инжиниринга разрабатываем идеи концепции продукта или услуги, или организационно-технической системы, или некоей системы систем как композиции из разных систем продуктов и систем деятельности. Если мы разработали концепцию, то на следующем шаге естественно попытаться детализировать ключевые компоненты этой концепции, чтобы добиться большей ясности. Тогда мы продолжаем системное проектирование и разрабатываем архитектурные модели системного инжиниринга. Хорошо. Разработали концепцию, разработали архитектурные модели, у нас есть образ, представление о том, что мы разрабатываем и каким образом этот продукт, эта услуга, эта система деятельности, эта система систем будет выглядеть, как она устроена, какие чертежи этой системы, какие модели. В этой ситуации полезно оценить наши результаты, нашу разработку, оценить ее не с точки зрения ценности, что мы делали до сих пор, а с точки зрения стоимости, то есть построить бизнес-модель. И вот идеи, которые мы разрабатываем, надо оценить через бизнес-модели и отобрать те идеи, те представления, которые экономически приемлемы для реализации. Если такие идеи появились, их можно разрабатывать, а для этого надо создать субъекта, который будет иметь дело с этой разработкой, то есть создать предприятие, которое будет иметь дело с продуктом, с его разработкой, с его созданием, с его применением, с его продвижением и так далее, то есть мы создаем предприятие, определяем бизнес-модель этого предприятия, а дальше расширяем сферу нашего анализа и проектируем систему менеджмента предприятия. Ну, если мы находимся в границах концептуального проектирования, то проектирование системы менеджмента тоже должно быть концептуальным, то есть верхнеуровневым, не детальным, но оно должно давать нам отчетливое представление, как будет устроено предприятие, которое работает с этим продуктом. Вот так примерно выглядит системная разработка, которой мы будем заниматься, но для отличников есть еще одна задачка. Она связана с переходом в мир новых механизмов, в мир новой экономики, в мир цифровой трансформации, то есть это мир, в котором до того, как вы делаете, вы разрабатываете модели, модели цифровизируете, создаете цифровых двойников, реальных объектов деятельности, и с использованием системных моделей и цифровых двойников, вы ведете деятельность. Вот эта экономика, вот этот мир, получил название цифровая экономика, и заключительным заданием мы рассмотрим вот варианты решений и попробуем построить варианты решений уже для тех предприятий, которые ориентируются на работу в умной цифровой экономике. Вот такой план. Хорошо. Давайте приступим уже к его реализации. Все элементы решений, которые мы будем применять, мы рассматривали в курсах программы 2.0, мы использовали специальные словари, показали специальные методологии, ну и сейчас в этой дипломной работе все эти термины, понятия, подходы, методологии вам потребуются. Но вместе, не по отдельности, а вместе. То есть что потребуется? Нужно понимание продукта, понимание, что такое услуга, что такое организационно-техническая система, как проводится системный инжиниринг продукта и услуги, что такое предприятие. Какого типа предприятия бывают, кто взаимодействует с предприятием, поставщики, потребители, что такое бизнес-модель предприятия. Конечно, потребуется понимание системы менеджмента предприятия как и системы организации и управления его деятельностью. Если мы двигаемся в цифровую экономику, то нам потребуется понимание IT-сервисов и технологий предприятия, 6-го и 7-го технологических укладов, например. Ну и дальше одно из требований цифровой, умной, экономики — это эпоха непрерывных, системных и цифровых трансформаций деятельности. Поэтому вам потребуется понимание таких понятий, как изменение, инженеринг, реинженеринг, улучшение, системное улучшение, цифровые трансформации деятельности. То есть потребуется то понимание, как вести непрерывное развитие решений, которое вы получили вчера. Поэтому вспоминаем словарь. И здесь можно порекомендовать ещё один такой хороший источник данных — словарь ISO 9000-2015. Он отлично представляет систему терминов, которые связаны с предметом этой курсовой работы, этой дипломной работы. Поэтому рекомендуется вам этот словарик держать недалеко от себя, ну и пользоваться. Теперь ещё раз напомним понятия, с которых мы начинаем. Система. Система — это совокупность взаимосвязанных и (или) взаимодействующих компонент, элементов. Если это система А, то она может состоять из компонент, элементов А1, А2, А3, и так далее. Примеры. Система предприятия, бизнес-система предприятия, система менеджмента предприятия, функциональная система менеджмента предприятия. То есть мы всё время имеем дело с разнообразными системами либо комбинациями, метакомпозициями этих систем. Поэтому мы рассматриваем правило проектирования применения отдельных систем и правила применения композиций этих систем, систем из систем. Системные системы — это совокупность взаимосвязанных и взаимодействующих подсистем, которые рассматриваются как единое целое. Система S — это есть совокупность подсистемы S1, S2, S3, и так далее. И они рассматриваются как целое. Модели и двойники — тоже очень важно для понимания — это то, что всё время должно быть в памяти оперативной. Исходными являются объекты, которые мы рассматриваем. Объект, сущность или метод, что-либо, воспринимаемое или воображаемое нами. Так говорит стандарт ISO. Модель. Модель — это заменитель объекта, который мы используем в прикладных целях. Двойник — это такая модель, которая используется как верифицируемый заменитель, как проверенный заменитель, как принятый заменитель, как релевантная модель объекта. Цифровой двойник — релевантная модель объекта, воплощённая в программном и аппаратном обеспечении. Почему мы эти понятия приводим? А потому что то, что нас окружает сегодня и будет окружать завтра, то есть умная цифровая экономика, демонстрирует тренд на тотальное применение системных и цифровых двойников в экономической деятельности, а значит и программа 2.0 тоже. Типовой приём работы с моделями. Вот он здесь представлен на слайде. При формировании моделей в первую очередь мы задаём сущности, которые составляют основу этих моделей. Сущности задаются, определяются, комментируются, поясняются. Всё это называется онтологической инженерией. Если мы задали какую-то сущность, например, требование к системе, требование к новому продукту, то эту сущность можно разделить на части, такое разделение называется иерархической таксономией. Мы разбиваем сущность на составляющие её компоненты и строим модели, которые называются иерархическими таксономиями сущностей. Один приём. Второй приём связан с тем, что мы устанавливаем связи между теми компонентами, которые мы выделили. У нас есть сущность А, мы её разделили на компоненты А1, А2, А3. И мы можем установить связи либо матрицы соответствия между компонентами А1, А2, А3. Что даёт такое рассмотрение? Что даёт такая матрица? Они позволяют нам устанавливать связи, фиксировать соответствия, фиксировать взаимодействия, определять конфликты, искать компромиссы в этих конфликтах, то есть это позволяет нам системно рассматривать объект моделирования, проектирования, применения и системно решать эти проблемы, иметь системные карты объекта. Ещё одна очень популярная модель — модель соответствий. И модель соответствий устанавливает соответствия между как элементами одной сущности, а может устанавливать соответствие между элементами разных сущностей. Поэтому модель соответствий — это модель, которая устанавливает в общем случае соответствие между элементами сущности А и сущности Б. Давайте продемонстрируем. Мы разрабатываем новый продукт. Собрали данные. Исходя из анализа данных мы сформулировали технические требования к этому продукту, если речь идёт о техническом продукте, о технической системе. Если мы сформировали технические требования, мы можем проверить эти требования на непротиворечивость, на конфликтность и гармонизировать необходимым образом. Требования задают то, что должно. Но чтобы реализовать требования, мы должны ввести к рассмотрению другие сущности, другие способы представления, которые помогают нам реализовать то, что должно. Следующий уровень представления — это функции. Функции показывают те предназначения, которые имеет система в целом либо её отдельные части. Функция показывает то, для чего система предназначена. Функции тоже можно разделить, мы получим дерево функций. Можно установить соответствие между функциями, как они взаимодействуют. А можно установить соответствие между требованиями и функциями. Состав функции должен быть сформирован так, чтобы закрывать требования. Все требования, которые мы сформулировали на предыдущем этапе, должны быть закрыты функциями. От функции можно перейти к компонентам. Компоненты — это составные части технической системы, это физические компоненты, если речь идёт о технической системе, и эти технические компоненты должны выполнять те самые функции, которые мы определили на предыдущем этапе. От компонент можно перейти к работам. Работы — это те действия, которые необходимо выполнить для того, чтобы разработать эти компоненты. Поэтому возникает такая система последовательного расширения архитектурного описания. Сначала требования и моделирование соответствий, потом функции и моделирование соответствий, потом компоненты и моделирование соответствий, потом работы и моделирование соответствий. Ну и поскольку у нас появились работы, от работ дальше можно перейти к системе менеджмента, то есть которые показывают, как будут организованы эти работы на предприятии. Вот этот анализ мы много будем применять по ходу выполнения нашего практикума, нашей дипломной работы, и он составляет основу архитектурного моделирования сложных систем, универсального архитектурного моделирования. А сами проекты разработки, сами проекты, прикладные проекты, которые мы разрабатываем, они могут иметь совершенную разную природу. И я бы так сказал, что существует большое разнообразие проектов системной разработки, которое разыгрывается на одной и той же системе компонент и элементов. Например, проект номер один. Описание и моделирование объекта как есть. Что даёт реализация такого проекта? Это инженеринг объекта как есть, такой инженеринг позволяет видеть устройство объекта, позволяет разрабатывать регламенты на основе моделирования, позволяет анализировать проблемы, с которыми сталкивается этот объект, и такое моделирование является исходным для системного проектирования. Такое моделирование выводит нас на системные карты. Проект номер два. Есть объект как есть, а мы разрабатываем концепцию этого объекта как надо. То есть такое моделирование, такой проект выводит нас на видение будущего нашего объекта. Проект номер три. Есть объект как есть. Мы смоделировали систему этого объекта как есть, и на основе моделирования и с учётом моделирования разработали концепцию как надо. То есть это более подробная версия, более детализированная версия проекта два. Ну и совсем детализированная версия, когда мы рассматриваем аккуратно все элементы, представленные на этом слайде. Объект как есть, моделируем систему как есть, анализируем систему как есть, разрабатываем концепцию системы как надо. Для концепции системы как надо исходя из этого разрабатываем модель системы как надо. Если у нас есть система как есть и система как надо, то мы можем построить программу изменений, программу-переход, дорожную карту, предложить проекты, которые переводят систему из точки А в точку Б, из ситуации как есть в ситуацию как надо. Ну и на финише мы получаем объект как надо. Вот так примерно можно строить и дипломную работу, то есть на этой карте надо выбрать границы и предмет вашего проекта в системной разработке. Хорошо, а теперь задание. Задание по первой теме. Просмотреть конспект, просмотреть видеолекцию, локализовать и выполнить задание эссе. Определить рассматриваемый объект, определить и обосновать миссию проекта системной разработки, продукта, услуги, системы. Определить обусловленное продуктом предприятие и его системы деятельности. Задать специфические термины. То есть я имею ввиду, если мы работаем в космической отрасли, у нас термины связаны, скажем, с космическим приборостроением. Если мы работаем в авиации, у нас инженерная терминология, связанная с авиастроением. Если мы разрабатываем подводную лодку, то у нас терминология связана с судостроением. И так далее. Ну и задать примерный перечень задач, принимаемых к решению в вашем проекте системной разработки, и этот перечень задач можно будет уточнять в рабочем порядке. Успехов!
