Олег Захарчук, АСиС Софт

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

Олег Захарчук, АСиС Софт

«По нашему мнению, цифровая экономика — это не только система цифровых платформ, которые обеспечивают связь между производителями и потребителями товаров и услуг. Понятие цифровой экономики включает еще и процессы, результаты деятельности, коммуникации… В рамках традиционной парадигмы ИТ-менеджмента построить цифровую экономику в таком широком смысле невозможно — нужно переходить к новой парадигме, нарушить устоявшиеся правила» — JSON.TV публикует полную расшифровку выступления Олега Захарчука, генерального директора «АСиС Софт», на семинаре «Построение экосистем предприятий с использованием единой цифровой платформы» 20 декабря 2017 г. в «Точке кипения» АСИ.

См. видеозапись выступления на JSON.TV

АСиС Софт» удалось применить данную модель в разработках ИТ-решений для самых разных областей деятельности:

управление наукоемкими проектами (Система для управления проектами Международного научно-технического центра, Интернет-система Фонда Бортника, Система управления ОКР для АО НИИ ТП);управление жизненным циклом сложных технических систем (Система оптимизации межремонтных пробегов подвижного состава железнодорожного транспорта, Интернет-система управления вагоноперевозками);система управления спортивными соревнованиями;система управления закупками и продажами.

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

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

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

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

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

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

Вот мы назвали с вами три типа объектов: процессы, результаты и отношения. Теперь давайте посмотрим, как каждый из этих типов объектов у нас может быть представлен в цифровом виде. С результатами у нас все достаточно хорошо. Мы можем представлять сложные технические системы в виде иерархий, состояний, поведения — так называемая модель Бунге-Ванда-Вебера, модель объектов-результатов. Мы научились хорошо представлять чертежи, 2D-представления, в электронном виде. Мы сейчас умеем работать с 3D-моделями, умеем даже некоторые изделия печатать на 3D-принтерах.

Цифровые отношения. Здесь тоже достаточно хорошо идет развитие этого направления. Это разные способы коммуникаций между людьми, между механизмами, датчиками и т. д. Это и цифровые валюты, «умные» контракты. То есть здесь всё идет, я считаю, нормально.

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

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

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

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

Для того, чтобы описать реальную деятельность, системы действий достаточно. Но когда мы хотим сделать систему управления, мы должны планировать деятельность. А для этого нам необходимо некие дополнительные объекты. Этими объектами являются задачи, работы, проекты, предприятия и т. д. — которые, по существу, группируют систему действий.

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

И если мы имели вот такую ситуацию...

… то с помощью вот этого фреймворка мы имеем уже достаточно ровненькое, сухое поле, да еще расчерченное на ровные дорожки.

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

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

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

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

Вот примерно так это всё происходит. Где-то что-то… какие-то задачи появляются, какие-то новые предприятия, подразделения, группы. Это картинка, которая показывает динамику изменения компании Autodesk. То есть нет ничего сейчас постоянного. И примерно так ведет себя пространство деятельности.

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

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

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

Прежде чем я перейду к демонстрации, еще два слайда. Все, наверное, знают известное представление бизнес-модели предприятий в трактовке Остервальдера. Мы это называем двумерной статической бизнес-моделью.

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

Так. Давайте мы зарегистрируем в системе какого-то нового пользователя и его организационную систему, там, какое-то его предприятие. … Всё. И теперь войдем...

Так, значит… Когда человек регистрируется, система создает некую начальную модель. Вот это вид для продвинутых пользователей, где вся деятельность происходит в тайм-шите. Есть вид для новых пользователей, где как бы рабочий стол, и есть две плитки: магазин решений, купленные решения. Но самое интересное здесь — это посмотреть именно ту бизнес-модель, которую система изначально построила. И сейчас мы ее посмотрим.

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

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

Само по себе предприятие не имеет никакого смысла, обязательно должны быть потребители для миссии предприятия, поставщики — что-то предприятие должно покупать и кому-то продавать. И вот мы сейчас зарегистрируем некоего поставщика, новое предприятие. … Когда мы зарегистрировали это новое предприятие, система точно так же для этого предприятия сформировала определенную инфраструктуру. И человек, зарегистрированный руководителем этого предприятия, может тоже входить и работать в системе точно так же, как входит этот руководитель, которого мы зарегистрировали. Ну вот, появился у нас «Поставщик 998». Мы его перетаскиваем и хотим ему что-то предложить. Система сразу нам дает список товаров и услуг организации, которые она предлагает. Но поскольку она у нас совершенно новая, то здесь ничего нет. Давайте зарегистрируем в магазине этой организации некий абстрактный товар и назначим какую-то цену — скажем, 55 тысяч. Он у нас появился, и мы его выбираем.

Вот. Значит, у нас сразу пошло извещение — это значит, что система тут же, как только вы кому-то что-то предложили, или он у вас что-то потребовал, она может уже генерить цепочку продаж. Сейчас мы посмотрим, что это за действия у нас появятся… А, это она предлагает, запускает сервис, выставить счет тому, кто хочет купить у вас этот товар. Ну, давайте мы формально это сделаем. Это я демонстрирую как бы те вещи, которые должны быть и есть в сегодняшних цифровых платформах для того, чтобы организовывать продажи и покупки. Выбираем счет и включаем… Всё, мы можем здесь отредактировать цену, но мы этого делать не будем. Всё, возвращаемся сюда. Что мы здесь можем видеть? Если мы тыкаем мышкой по стрелке, то мы можем видеть, что у нас есть товар. Мы для этого товара можем вообще посмотреть свойства-обязательства. То есть это так называемые обязательства: что за товар, по какой цене он у нас продается, связать с расходами-доходами потребителя-поставщика. Почему? Потому что как только мы это сделали, в принципе, система уже видит и может формировать бюджет предприятия: как бюджет продавца, так и бюджет потребителя. Она уже сформировала денежный поток, некие финансы. Потому что как только мы выставили счет, она сформировала обратный поток денег по этому счету. И мы по обратному потоку можем формировать, там, авансы, расчеты и т. д.

Ну вот, посмотрим бюджет доходов и расходов — что у нас получается. Вот мы видим, что у нас есть продажа товара «123» по плану 55 тысяч, и уже по факту есть… Факт — это мы считаем по выставленным счетам. То есть мы продали на 55 тысяч. Ну, соответственно, если мы выберем поставщика, то мы тоже получим бюджет, но уже с минусом: он купил на 55 тысяч. Вот он купил на 55 тысяч. Если мы войдем под поставщиком, то там, соответственно, будет извещение, что вот, вам выставлен счет, просьба оплатить. И тогда мы можем смотреть бюджеты потоков денег. И эти бюджеты могут считаться не только для предприятия, они могут считаться для группы предприятий, для корпораций, для отраслей и вообще для всей экономики, по потокам.

Что мы еще интересного здесь можем посмотреть. Мы можем посмотреть вот эти уровни, о которых я говорил — что есть многоуровневый слой. Если мы посмотрим от Тестова… И перейдем на уровень проектов — то мы увидим картину… Вот здесь она показывает, на каком уровне мы находимся. А у нас ситуация следующая. У нас предприятие — это особый вид проекта — как, в общем-то, и по определению. А когда мы опускаемся на уровень проектов, мы предприятие рассматриваем как проект и туда же включаем привычные проекты. Чтобы у нас были некие проекты, в которых участвует много организаций.

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

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

Сейчас посмотрим, можем даже это как-то отразить… Вот. То есть пригласить предприятие. Ну вот, давайте мы пригласим, например, наше предприятие. Вводим логин, она проверяет, есть ли пользователь — найден. И далее отправляется уже по процессу запрос. Я должен войти под собой. И, соответственно, что-то система мне скажет. «Рассмотреть приглашение в работу». Я открываю. Так: «Сотрудник Тестов Иван Иванович, TestovLtd, приглашает вас в работу соответствующую». Я принимаю приглашение. И теперь я уже виден в той экосистеме, и можно работать дальше. О, еще извещение, что принято приглашение в работу. Ну, это уже не столь важно, нам важнее бизнес-модель. Вот, появилось предприятие «АСис Софт». Мы соответствующим образом перетаскиваем и хотим предложить, что это предприятие даст. Ну, у нас в магазине много чего. Давайте базу данных какую-нибудь предложим. Она у нас без цены, но это неважно. Выбираем и, соответственно, она у нас на стрелке появляется. То есть у нас может идти много товаров и услуг по одной стрелке. Просто для того, чтобы компактным образом на схеме это отображать, мы отображаем в виде одной стрелки. Но она может быть двусторонняя, когда у нас идут обратные потоки, то здесь она отображается.

Дальше интересная ситуация следующая. Вот предприятие Testovхочет поставить, там, предприятию-поставщику какой-то товар. Откуда оно его возьмет? Естественно, оно может его купить в другой организации. Ну, это мы показали — что можно на вход. Но интересно, что она может и сама произвести. И вы можете построить прямо с помощью такого конструктора внутреннюю модель предприятия — как именно произвести вот этот товар. И здесь мы даже построили для этого специальный процесс, даже мы сделаем это так… Он у нас — выходное обязательство… Вот. «Запустить процесс, делегировать обязательства на вход». Поскольку у нас в системе любой вид деятельности — процессы, проекты, кейсы, — то сейчас мы запускаем конкретный процесс и даже можем посмотреть некую схему этого процесса, экземпляр процесса. Вот он. Что из себя представляет этот процесс — это вот мы в экземпляре уже запустили первое действие, мы удостоверились, что выбрали правильное действие. А дальше три варианта, откуда мы можем взять реальный товар на предприятии. Мы можем его взять из какого-то функционального подразделения. Мы его можем взять из проекта, который мы зарегистрируем, создадим в предприятии. Или мы его можем заказать в каком-то типовом процессе, технологическом процессе и т. д. Как говорится, других вариантов… Ну я не знаю, можно, конечно, придумать, но вряд ли они будут чем-то особенно отличаться.

Вот. И сейчас мы этот процесс дальше протянем, посмотрим. Вот: «Функциональное подразделение — проект — процесс». Но мы пока его выполнять не будем. Поскольку у нас есть один директор, давайте мы для интереса создадим еще какого-нибудь сотрудника в рамках структуры предприятия. Создадим еще подразделение и сюда назначим руководителя. «Создать». Вот.

Теперь давайте мы в проекте сделаем этот… будем создавать этот товар. Система сразу по проекту нам предлагает зарегистрировать новый проект. Ну, давайте проект «ОКР». Начало, какое-то окончание… Менеджер — Сидоров, начальник подразделения, вот как раз. «На выполнение». И хотим получить на выходе некий типовой модуль. Так, система зарегистрировала проект. Смотрим далее, что получается у нас. А у нас далее система сделает обязательство, то есть свяжет связанный проект, то есть область деятельности «проект», стрелкой-обязательством с нашим предприятием. И здесь это как раз и прописывается. Ну, и по существу на том этот процесс закончился. Но как у нас это отразилось на нашей бизнес-модели? Давайте мы это и посмотрим. Мы сейчас находимся на уровне предприятий, а опустимся на уровень проектов. Мы видим, что появился проект. И уже этот проект поставляет нам вот этот новый товар. Мы по проекту можем посмотреть некий график, он у нас здесь, в общем-то, простой, потому что мы ничего конкретного не указали. Можем какие-то сроки назначить ему...

Но здесь мы можем можем применить некую автоматизацию. Дело в том, что так же, как мы формируем автоматически некие модели предприятия, мы можем формировать и модели проектов. И здесь я вам как раз покажу недавнюю работу, которую мы как раз с Сергеем Павловичем делали, мы называем ее перевод стандартов исполняемой модели управления ОКРами. Вот мы возьмем проект, возьмем карточку проекта. Мы в проекте уже указали, что на выходе мы должны получить типовой модуль радиоэлектронной аппаратуры. В системе введены некие шаблоны из стандартов, что опытно-конструкторская работа должна состоять из таких-то этапов, там, аванпроект, эскизный проект, технический проект, изготовление и т. д. На каждом проекте по стандартам должны выпускаться определенные типы документов. И т. д. И мы просто нажимаем модель «ОКР». Система сейчас, в течение, там, 40 секунд сформирует, по существу, график проекта полномасштабный. И если мы зададим ресурсы на предприятии, то есть укажем, что такой-то сотрудник будет выполнять роль главного конструктора, такой-то сотрудник схемотехника, такой-то сотрудник нормоконтролера и т. д., то система назначит на соответствующие работы этих сотрудников сразу. И что мы увидим. Если мы посмотрим теперь график проекта, то мы увидим, что у нас действительно получился некий большой график, в соответствии с ГОСТом. То есть у нас есть 6 этапов ОКРа, и в соответствии с этими этапами мы имеем график работ.

Интересно очень, как дальше управлять этим проектом. То есть система умеет мониторить исполнение обязательств, и она не допускает накопления большого количества срывов. Потому что… Почему мы так плохо управляем сложными проектами и т. д.? Потому, что мы нарисовали график, а потом через месяц смотрим — а всё уплыло, и у нас вообще среди, там, сотни работ 50% сорвано. Руки опускаются, все бросают этот график и начинают «тушить пожар». Здесь система каждый день мониторит, то есть запускается бот, и он просматривает каждое обязательство и т. д.

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

Так, что я хотел показать… Ага. Значит, календарь — вот «коррекция». Давайте мы посмотрим, что нам бот намониторил. «Индикатор — проект».

Голос системы: Внимание, в проекте есть просроченные выходные обязательства. Количество — 1.

Олег Захарчук: Так, вот здесь у нас выходные обязательства. Смотрим, где что просрочено. И можем посмотреть по логистической цепочке, кто же у нас слабое звено в этой цепочке. Значит, слабое звено… И вот, у нас видно, что был некий комплект конструкторской документации, и вот здесь вот эти два последних обязательства привели к тому, что у нас срыв обязательства по полному комплекту конструкторской документации. Вот такая штука.

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

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

Уральский федеральный округ. «Показать связи выделенного предприятия». Раз — и теперь карта коммуникаций. Вот. Ну, он у нас как бы дальше не представлен. По-моему, у нас там другой округ декомпозирован. Давайте мы посмотрим… «Карта коммуникаций»… О, Сибирский, по-моему у нас декомпозирован. «Карта»… То есть я хочу опуститься таким образом до уровня вообще предприятий, с которыми мы работаем. Например, с Железногорском в Красноярском крае, космическим НПО «ПМ». В принципе, по данной схеме мы можем опуститься до уровня любого предприятия. И самое интересное, это всё можно наблюдать с самого центра. «Красноярск»… Ну вот, мы бизнес-модель посмотрим, потому что там уже на карте, по-моему, координаты не заданы. Вот: Красноярский край. И здесь вот есть Железногорск. «Показать связи выделенного предприятия». А в Железногорске у нас есть НПО «ПМ». И дальше в НПО «ПМ» я могу посмотреть, как у меня уже происходит деятельность внутри НПО «ПМ». Перехожу на уровень проектов, если они есть. Перехожу на уровни работ, соответственно. Перехожу на уровень задач. И так до уровня действий любого сотрудника. Был у нас тут… Ну, поскольку сотрудники — это у нас… директор в системе не работал, соответственно, здесь и действий никаких у него нет.

Конец презентации

Обсуждение, сессия вопросов-ответов

Реплика из зала: Хорошо, скажите. Вы, наверное, анализируете финансовую работу государства… Скажите, вот что ждет «Газпром»? На примере анализа, допустим, три года. Они на 10 лет построили видение инвестиционное, да… И с радостью, со своей радостью, заверим, что все проблемы «Газпрома» мы тогда рассчитали. Без вот этого...

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

Реплика из зала: Когда вы пишете вначале «Цифровая экономика», вы вносите в умы наших управляющих решение некую аллюзию — о том, что они сейчас посадят мальчиков-девочек на вашу систему, они там что-то научатся делать, и заживем счастливо. А когда мы...

Олег Захарчук: Наше правительство сегодня именно работает таким образом, как вы говорите. Оно берет некую BigData и анализирует, что происходило. А потом на основе этих данных прогнозирует — а что надо спланировать.

Реплика из зала: Оно не прогнозирует, оно кому-то продает..., у кого-то покупает...

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

Реплика из зала: Можно тогда еще раз вопрос: у вас есть какая-нибудь проработанная область, в которой сейчас мы постараемся вам сгенерировать так называемого «черного лебедя» — и посмотрим, как вы на это ответите.

Олег Захарчук: У нас есть проработанная область — система управления вагоноперевозками.

Реплика из зала: Вагоноперевозками, замечательно. Я вагоны не очень знаю, но, например, про контейнерные перевозки. Какого «черного лебедя» в контейнерных перевозках вы можете спрогнозировать в 2018 году?

Олег Захарчук: То есть поскольку мы учитываем, мы имеем связь с базой данных РЖД… Вот у нас, кстати, если вы смотрели, много рекомендательных писем из организаций РЖД.

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

Реплика из зала: Сейчас не хватает… вагонов… При этом очень много не хватает...

Олег Захарчук: Конечно, конечно. Понимаете, система накапливает информацию точно так же, как информация накапливается в Интернете. Только она накапливается структурно.

Реплика из зала: Она накапливается. Просто, может быть, мы ее в базах данных не видим. Но раз информация появляется...

Реплика из зала: Вот ключевой момент вы сказали...

Реплика из зала: В ней она существует. Но это абсолютно не говорит о том, что ваша система поддерживает прогнозирование.

Олег Захарчук: У нас… Я могу сказать. Я говорю не на уровне «система поддерживает прогнозирование». В этом смысле надо говорить: есть микросервисы, которые просчитывают и дают прогноз на основе информации, которая лежит в системе — там, за год, за два, за три. Вот, например, как мы планируем и улучшаем планирование проектов НИОКР? Мы смотрим, какие проекты уже прошли, какие трудоемкости закладывались там, какие реально были трудоемкости. И эту информацию мы берем при прогнозировании и постройки графика новых проектов. То есть система уже сразу подсказывает, что вот этот тип...

Реплика из зала: В плане поддержки текущей деятельности это замечательно, очень здорово и я в принципе, наверное, … сейчас. Потому что до этого только критику слышал.

Олег Захарчук: На самом деле, здесь, я говорю, можно построить микросервисы прогнозирования. И даже мы планируем делать специальные API, где разработчики, сторонние, индивидуальные, других организаций и т. д., могут делать свои микросервисы, располагать в своих ЦОДах, на своих сайтах и использовать в нашей системе. Они просто регистрируются у нас, и всё.

Реплика из зала: А заказчик, который придет вот к этим молодым ребятам, которые сделали...

Олег Захарчук: А они выставят свои микросервисы в магазине.

Реплика из зала: А про вас не узнают. Они просто в их микросервис зайдут, а они внутри как бы...

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

Реплика из зала: То есть вы все-таки пытаетесь нам казино показать, да?

Олег Захарчук: Ну, в общем-то, да.

Реплика из зала: А кто ваш конкурент — чтобы мы могли понять, есть ли смысл только в вашем казино обслуживаться?

Олег Захарчук: Скажем так, на основе единой модели — пока никто. В плане зоопарка — пожалуйста, там, скажем, магазины Google и т. д. и т. п. А вот в плане того, чтобы этот зоопарк понимал один язык, одну модель, — пока нет. Я общался с разными вендорами, представителями и т. д. Oracle, SAP и т. д. Они подтверждают, что вот такого слоя, котрый бы объединял все их решения, у них нет и не предвидится даже.

Реплика из зала: А тогда… Не ждет ли нас опасность, что мы сначала в вам поверим, привлечем своих клиентов через наши сервисы, которые наши парни разработали, вы начнете их регистрировать, собирать базу из этих наших клиентов. А потом кто-то придет, вас победит, и нам надо будет потом к ним перебегать?

Олег Захарчук: Нет, он может победить только в том случае, если он всё это купит и будет использовать.

Реплика из зала: Например, так. Тоже вариант. Поэтому мы и хотим узнать, как сделать так, чтобы...

Олег Захарчук: Поэтому я апеллирую к государству. Я говорю, что государство говорит: цифровая экономика, цифровая экономика… Давайте делать цифровую экономику с таким подходом на такой платформе. Я не говорю обязательно на этой. Потому что я говорю, что это прототип…

Реплика из зала: Вот у вас там получается такая цепочка поставщиков, да?

Олег Захарчук: Да.

Реплика из зала: Тематика, или инструментарий управления конфликтами этих цепочек поставщиков: срок и т. д. здесь есть?

Олег Захарчук: Я понял. Мы сейчас работаем над такими сервисами, которые как раз смотрят эти конфликты. Это связано с теорией ограничений и построения кратчайших путей с учетом загруженности ресурсов, использования буферов и т. д. Это что касается проектного управления. Но это очень сильно...

Реплика из зала: Всё, я логику понял. Следующий вопрос — общие данные в цепочке поставщиков.

Олег Захарчук: Общие данные — это, на самом деле, общие их товары и услуги, общие объекты инфраструктуры...

Реплика из зала: У меня предприятие, у меня доступ к другому предприятию. Данные как-то централизованы?

Олег Захарчук: Через единый магазин товаров и услуг.

Реплика из зала: Я понял. Следующий вопрос: у меня порядка 300-400 тыс. работ в графике. Масштабируемость?

Олег Захарчук: Ситуация следующая. Очень хороший вопрос. Мы решаем эту проблему двумя путями. Первый путь: у нас же есть два уровня, которые позволяют нам гораздо лучше представлять графики. То есть у нас есть уровень работ, а внутри работ есть еще иерархия задач. То есть это некая холархия, на самом деле. И в чем проблема-то единого графика Гантта. В том что, действительно, когда вы пытаетесь там всё учесть, у вас появляются тысячи вот этих работ. Мы говорим следующее: вы на уровне работ делаете график с ограниченным числом этих работ — например, сто, но самых главных. А то, что не самое главное, но обязательно требуется, вы опускаете внутрь этих работ и уже делаете задачами. Потому что… Я могу сейчас открыть и показать, что у нас есть график работ, а внутри работ есть график задач. Это один момент. То есть у нас графики работ гораздо лаконичнее появляются, чем вообще графики работ.

А второе… Масштабируемость. Ну, система, на самом деле, имеет микросервисную архитектуру. То есть у нас сервисы могут работать на серверах, расположенных по всей планете. И поэтому нагрузка ложится на каждый сервер отдельно. Это раз. Сейчас у нас эта система в одном месте, в московском ЦОДе DataLine, но это самый большой, самый лучший ЦОД по рейтингу в России. И третий момент. Ну вот эта же архитектура использовалась в фонде Бортника. И по существу, она показала, что пиковые нагрузки, где там тысячи одновременно работающих ученых, которые в последнюю ночь заполняют заявки… Это даже был не ЦОД, это просто один сервер стоял — выдерживал это дело.

Реплика из зала: У вас там Гантт представлен. Внутри него что, сетевая модель, или просто картинка? Если сетевая модель, расчетное списаниетам есть?

Олег Захарчук: Внутри него не только сетевая модель. Внутри него логистическая модель. То есть у нас работы между собой связаны этими стрелками-обязательствами, по которым идут объекты. То есть у нас есть два типа отношений между работами: отношения привычные, последовательность действий, то есть одна работа может начинаться после другой и т. д. А другой тип отношений — это связь работы как процесса. То есть что одна работа поставляет… И вот здесь, кстати, мы нарушили именно правило общее. То есть традиционно считается, что процесс — это типовой процесс. А проект — это уникальная деятельность. Мы говорим, что любая деятельность — это процесс. В том смысле, как он определяется в стандарте ISO 9000. Там говорится, что процесс — это деятельность по преобразованию входа в выходы. И выходы потребляются следующим процессом. Но ни слова не говорится, что это некая повторяемость. Отсюда уже все переходят, и все стандарты говорят, что проект — это уникальный процесс. А типовой процесс — это… А процесс, в нынешнем понимании, — это типовой процесс. Получается, что как бы любая деятельность — это процесс. Ну, и мы всё время в споре с нашей международной ассоциацией по управлению процессами. Они, типа: нет, это неправильно и т. д. Но как-то в последнее время что-то они...

Реплика из зала: Спасибо большое за ответ, передаю слово.

Олег Захарчук: Да, пожалуйста.

Реплика из зала: Можно я? На чем вы вообще пишете? Сама разработка на чем основана? База данных? На чем хоститесь и т. д. То есть какой принцип автоматизации?

Олег Захарчук: Объясняю. Первая версия этой системы, платформы, была сделана где-то в 2005 году на C++, builder 5 тогда еще был. И это тоже был сервисный подход, но для Windows-среды. Сейчас это всё сделано для интернет-среды, то есть ASP.NET. В основном Ajax, JavaScript используется. База данных пока — SQL Server. Но мы смотрим...

Реплика из зала: Какой SQL Server?

Олег Захарчук: 2012-й сейчас. r2.Но мы смотрим сейчас разные варианты перехода на объектные базы данных, распределенные. Потому что у нас сама система, сама модель-то объектная. И, в общем-то, есть варианты, и даже отечественные, в принципе. И система делается именно так, что у нас сервисы, интерфейсы отдельно, а слой работы с базой отдельно. То есть мы можем достаточно легко перейти на другую базу. И мы мыслим точно так же организовать хранение данных, как у нас сервисы: распределить по всей планете, о разным ЦОДам и т. д. Чтобы не было вообще проблем с масштабируемостью.

Реплика из зала: То есть вы оптимистично относитесь к политической обстановке?

Олег Захарчук: В общем-то, да. Хотя, вот я говорю, что… Поскольку метамодель одна для разных уровней — для микроуровня, для макроуровня, для глобального уровня экономики, — то здесь… Мы, например, можем выращивать систему где-то в одном месте, на одном предприятии, потом на другом, на третьем, а потом хоп! — и их объединить.

Реплика из зала: Сколько может система обрабатывать запросов единовременно? Если вы говорите, что можно подключить огромное количество подрядчиков, контрагентов и т. д. Сколько можно обрабатывать единовременно?

Олег Захарчук: Вы знаете, это как раз… Почему я говорю именно о прототипе системы, а не о промышленном образце. Потому что если бы я сказал о прототипе системы, я бы вам ответил сразу на этот вопрос. Когда мы будем переходить на промышленный образец, мы будем проводить нагрузочные испытания и т. д., замерять эти вещи. Но я могу сказать тоже, что… Учитывая то, какими сейчас стойками, вагонами и т. д. строятся ЦОДы… На самом деле, если уж наша система не будет работать, то никакая система не будет работать. Потому что я не сказал одну важную вещь: на самом деле, я вот объясняю вам, что это система действий и т. д. и т. п. Но в самом-то корне этой системы один объект. И вообще любой запрос, который в системе, получается, мы можем всегда свести к плоскому — то есть к одной строчке. А это как бы самый быстрый вариант любых вычислений — когда у нас плоский запрос. И мы, кстати, сейчас имеем такой пример. У нас есть одна очень большая база данных, где миллионы записей. Это… Нам, правда, заказчик запрещает говорить о ней, поэтому я вам могу сказать только потом как-нибудь. Но там миллионы записей, по всему миру данные собираются и строится некая система. Она работает, она обрабатывается. И самое интересное: когда у нас возникла проблема генерации отчетов, скажем… ну, десятки тысяч записей. Мы сначала этот формировали, используя обычный SQL-запрос, потом действительно начались тормоза. А потом мы просто сделали вид и проиндексировали. Индексация — это что значит? Что она берет и переводит всё в плоскую таблицу. Вот. И с 10 минут стало 10 секунд.

Реплика из зала: А безопасность? При наличии огромного количества информации, которая представляет собой профессиональную, а то и государственную тайну? Если это госзаказчик...

Олег Захарчук: Я понял. Скажем так… Естественно, если система требует, там, безопасности, то это https, то есть шифруется передача. Во-вторых, это всё в ЦОДе, и львиную часть безопасности на себя берет ЦОД, это прописывается в договоре. Мы даже смотрели… ЦОД вообще может наши сервера, если там супербезопасность, опечатывать и т. д. и никого туда не пускать. Ну а так, дальше, — традиционные системы безопасности, пароли-логины, шифрование и т. д.

Реплика из зала: Олег, а защита от вранья? Уголовный кодекс?

Олег Захарчук: Нет, ситуация следующая… Очень хороший вопрос. То есть вот смотрите. Каждый пользователь, если он работает в системе, он выполняет свою деятельность, выполняет какие-то функции, и это преобразуется в его действия. Он не задумывается о том, что он делает конкретно, просто ему система подсказывает: сделай то, сделай это… Система сама потом формирует за него отчет: сколько он отработал там, что он сделал, какие результаты появились, какие характеристики после его деятельности...

Реплика из зала: Но какие-то исходные данные он должен внести всё-таки. Вот здесь он может наврать.

Олег Захарчук: Но вы знаете, всё же это фиксируется. Если он наврал, то всё равно размотать можно. То есть тут главное, что если он один раз наврал, размотали, другой раз наврал, размотали, то он понимает: что бы он ни делал, всё равно всё прозрачно.

Реплика из зала: Вы думаете, разматывается?

Олег Захарчук: Разматывается.

Реплика из зала: То есть можно понять, где вранье пролетело, и начать...

Олег Захарчук: Разматывается. Потому что в этом-то соль системы. Система строится из отношений между действиями.

Реплика из зала: Да нет, вранье просто поменяет эти отношения, как-то изменит весь этот баланс. И непонятно, он изменил соотношение...

Олег Захарчук: Понимаете, можно обмануть одного человека, другого и т. д. Но нельзя обмануть систему, если она со всех сторон это дело просматривает.

Реплика из зала: Так это блокчейн. А у вас не очень блокчейн...

Олег Захарчук: Ситуация… Вот блокчейн — хорошо. Я вам не зря нарисовал эти стрелки. Это, на самом деле, следующее: на уровне предприятий эти стрелки — на самом деле, это «умные» контракты. Почему? Потому, что мы указываем: такое-то изделие с такими-то характеристиками должно быть поставлено с такой-то ценой, даже риск указываем. И система начинает мониторить. Она этот контракт закроет только...

Реплика из зала: То есть стороны этого контракта, там, слева-справа, могут заметить, что вранье?

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

Реплика из зала: Расчетов очень много...

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

Реплика из зала: Нет, она может по-другому действовать, она может балансы проверять...

Олег Захарчук: Да, она проверяет еще… И мы, на самом деле, сделали что? Вот когда в бытность мою главным конструктором систем ориентации и навигации меня всё время напрягала работа подготовки договоров. Причем для контрагентов надо было тоже считать сметы, прямые расходы, косвенные налоги и т. д. И была поставлена такая задача, чтобы сделать формирование договоров со всеми приложениями нажатием одной кнопки. И оказывается, что мы придумали, как решать эту систему уравнений. То есть мы сегодня можем любую логистическую цепочку просчитать с любыми прямыми и косвенными затратами, решив большую систему уравнений, и посчитать ее баланс. Что, по существу, круговой интеграл, через границу потоки идут, и всё. Потому что то, что внутри, зануляется. И мы увидели, что, оказывается, когда-то в Советском Союзе считался бюджет таким образом. И мы пришли к системе ОГАС, которая когда-то была анонсирована, ее заблокировал Политбюро. Но Советский Союз был уже недалеко от того, чтобы сделать некую единую систему расчета. Было всё готово. Спасло только мир от того, чтобы мы это всё считали — развал. На самом деле, в статьях пишут, что к этому приложили руки и всякие зарубежные...

Реплика из зала: Предложениекороткого названия вашей системы: «Два- Леонтьев». Первый Леонтьев, который занимался межотраслевыми балансами, лауреат Нобелевской премии. Вы просто ниже опускаетесь. У вас баланс межотраслевой, вы можете дальше опуститься… А второй Леонтьев — психолог, который занимался деятельностным подходом в психологии человека.

Олег Захарчук: Ну, спасибо! Это очень лестно.

Реплика из зала: Олег, а можно конкретный вопрос?

Олег Захарчук: Да-да...

Реплика из зала: Достаточно конкретный.

Вот вы говорите, что система отражает реальность. То есть, с одной стороны, вы открываете проект, и она сразу прописывает все мои сроки, все мои работы — что там, типовой проект какой-то? А если не типовой? Если я должен придумать эти сроки?

Олег Захарчук: Ситуация следующая. Вы имеете возможность нарисовать и придумать сами. Это так называемый начальный уровень, мы все так работали. Но если вы посмотрите, например, стандарты по управлению проектами и т. д., то в стандартах прописано, что должны быть такие-то процессы.

Реплика из зала: Ну, хорошо.

Олег Захарчук: В стандартах, например, по ОКРам прописано, что должны быть такие-то этапы. Так вот, это всё...

Реплика из зала: А сроки?

Олег Захарчук: А сроки берутся откуда… Я думаю, что напрошусь еще на один семинар, именно управление научно-техническими проектами, где я покажу сервисы, где мы вводим типовые результаты, типовые документы. Например, схема электрическая Э3, в ней участвует, там, схемотехник и т. д. Примерно класс аппаратуры, радиоэлектронная аппаратура. Мы прописываем, что емкость такая-то...

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

Олег Захарчук: Ну, это нулевой уровень. Она у вас генерит: вот это типовой, график...

Реплика из зала: А потом я могу ее под себя...

Олег Захарчук: Конечно! Не только потом — вы будете постоянно всё это двигать.

Реплика из зала: Просто когда я чувствую, что у меня что-то нестыковки, то я могу снова это перерегулировать...

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

Реплика из зала: А то мне показалось сначала, что она вроде от жизни отталкивается, а потом жизнь и навязывает. И я должен под нее подстраиваться.

Олег Захарчук: Нет, это просто...

Реплика из зала: То есть она не навязывает?

Олег Захарчук: Не навязывает, это супергибкая система. Я не показал вам еще кейсы вот этого. Просто народ устал, и как-то не до этого. То есть...

Реплика из зала: Практический вопрос.

Олег Захарчук: Да.

Реплика из зала: Простите, до свидания, спасибо большое.

Реплика из зала: Сколько времени понадобится, чтобы на этой платформе сделать вот не Яндекс.Такси, а АСис.Такси? Управление деятельностью, там, водителей, потребителей. Вот в этой архитектуре по времени?

Олег Захарчук: На самом деле, я думаю, месяца 2-3. Если хорошо сесть, то можно сделать. Поскольку мы будем делать только микросервисы. То есть мы не будем делать ту работу, которая делается, когда начинается новая система: создается бизнес-архитектура, создается ИТ-архитектура и т. д. У нас уже вот это всё есть. Мы сделаем только сервис.

Реплика из зала: 2-3 месяца — это с какой численностью коллектива?

Олег Захарчук: Человека 2-3. То есть я могу сказать, что если делать систему на этой платформе, то это в 2-3-4-5 раз дешевле и быстрее получается, чем обычным способом.

Реплика из зала: То есть 6 человеко-месяцев — и будет Асис.Такси, условно, полностью повторять...

Олег Захарчук: Понимаете, это экосистема. Вот здесь я показываю сейчас, в том числе, то, что уже есть рабочее. Я специально даже завожу тестовые, чтобы нагружать систему вот этим мусором. Она уже грузится несколько лет, этим мусором. Она работает нормально, и здесь экосистема предприятия и физических лиц. То есть как бы вот этот «бульон» действительно есть. Но это так реально всё работает. Но это только так кажется, что это бульон.

Реплика из зала: Нет, для того, чтобы управлять, отражать мало. Туда надо вшивать какие-то уже решения автоматические — что она автоматически должна уже что-то перераспределять. Опережать жизнь. Смотреть, где она опережает жизнь, а потом уже в каких-то моментах она уже диктует жизнь: делай так...

Олег Захарчук: Мы сюда уже сейчас включаем микросервисы для связи с интернет-вещами. То есть они будут просто получать данные. И, например, когда у нас строится «умное» предприятие, где «умные» технологические процессы, нам нужна информация с разных датчиков. Это уровень одного сервиса. То есть есть проблемы уровня системы, которые, мы считаем, мы решили. А есть проблемы уровня сервисов, которые мы, в общем-то даже и не беремся… Мы говорим, давайте сервисы будут делать другие. То есть здесь всё можно строить как угодно. Главное — не отходить от этой общей концепции: что есть процессы, результаты и отношения.

Реплика из зала: Подскажите, а прогнозирование? Прогноз — это самый сложный и щепетильный вопрос. Производить железо — это… Какими данными вы пользуетесь? Ну, создали стартап, не знаю, запустили эту систему…Какими данными вы… И где вы их берете? Мы говорим о структурированных данных. Чтобы в итоге делать прогноз?

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

А дальше что мы имеем? Мы имеем набор данных, который говорит, что вот, получились примерно одни и те же результаты, но разными путями. Дальше мы, в принципе, можем запустить некий сервис, который нам сделает оптимальный с точки зрения стоимости процесс создания какого-то результата. Это уже как бы элемент самообучения. Либо самый эффективный с точки зрения качества процесс — это другой момент. Теперь: еще в плане дальнего прогноза. Поскольку система накапливает информацию, она накапливает не только результаты и как они рождались. Она накапливает цепочки действий. Она как бы думает некими цепочками.

Реплика из зала: Мы понимаем, о чем вы. Но мы берем базовую точку — стартап, то есть ноль. Истории нет. Каким образом и что туда закладывается? Вы привлекаете сторонних людей через...

Олег Захарчук: Стартап — это вы строите

Реплика из зала: То есть итоги, прогнозы мы не сможем сделать, или...

Реплика из зала: Прогноз из нуля равен нулю.

Реплика из зала: Есть предметная область, которая планирует свою деятельность. А это инструмент, который позволит вам это делать быстро, эффективно и без запинок.

Олег Захарчук: Из головы вынуть и положить туда информацию, которая вам не нужна

Реплика из зала: Тогда вводную можно в эту систему заложить полную, то есть мы привлекаем Яндекс, он дает вам данные, делает определенный прогноз, и вы сюда запускаете. Это возможно через открытый код.

Олег Захарчук: Конечно. Другим языком можно сказать так. Мы делаем сервис интеграции с некими сервисами Яндекса, которые получают оттуда какую-то информацию, и мы ее используем. И всё. API свободное.

Олег Захарчук: Очень важный момент я могу добавить — как мы, например, переходим из одной области в другую, совершенно не связанную. Вот у нас есть область управления проектами. Есть проект, работа, задача, действие. А тут мы перешли, в 2010 году запустили систему управления приемными комиссиями МИФИ, где потом нас попросили вообще создать модель виртуального университета. Мы просто сделали следующее. Мы оставили проект процесс-задача-действие, мы просто из по-другому назвали. Проект — это некая, так скажем, программа. Работа — это может быть в программе… Программа — это типовой процесс. Проект — это курс какой-то. Работа — это занятие. Задачи — участие студентов. Действия — это действия студентов и т. д. То есть мы полностью на этой же модели описали деятельность университета. Мы делали там по соревнованию вещи — то есть у нас тоже там, скажем, турнир — это проект, соревнование — это работа, участник соревнования — это задача, действия — это какие-то действия, выполненные спортсменом в этом соревновании. И на самом деле, какие бы области мы ни затрагивали, в общем-то, всегда описывается он одним и тем же. И мы видим, если смотрим разные системы — те же самые управление проектами, ERP, CRM и т. д., — там очень много чего пересекается. Просто пересекается. Просто они строились сверху, и как бы не задавалась проблема, чтобы построить нечто универсальное.

Реплика из зала: Еще вопрос. Храните данные, как вы пояснили, в облаках?

Олег Захарчук: Да.

Реплика из зала: Насколько мы знаем, если посмотрим, соответственно, некие отзывы, то уважаемые корпоративные структуры, которые перешли определенную точку N, они для облаков имеют исключительно локальные какие-то зоны. А все остальные, ключевые, стратегические управляющие данные хранят на своих серверах. Потому идет вопрос. Ваша структура колоссальная и охватывает большой массив данных. Вы всё же также предусматриваете даже ключевые стратегические данные, которые влияют на работоспособность, будете хранить в облаках?

Олег Захарчук: Нет, ситуация следующая. Вот что значит облака? Облака — это те же самые сервера, которые стоят в корпорациях и т. д., только общего пользования. И под облаками я могу понимать вообще все сервера, и частные, и общие. То есть в корпорации можно назвать это частным облаком. Если речь идет о глобальной системе на уровне экономики, я бы, наверное, предложил это всё распределить равномерно по разным надежным облакам. Но здесь я не делаю акцент, частное облако, общественное облако и т.д.

Реплика из зала: Смотрите, ваша новая парадигма, этот треугольник, то есть процессы-результаты-отношения. А снизу что, я не совсем понял? Вы говорите не идти сверху, а идти снизу. Что значит у вас, снизу мы идем?

Олег Захарчук: Снизу — это значит что? Что деятельность — это цепочка действий просто. То есть вот вы выполнили одно действие, другое действие, третье действие, четвертое и т. д. То есть мы, выполняя действия, вообще можем не знать о существовании каких-то проектов, предприятий и т. д. Мы просто выполняем деятельность. Когда проектируются системы, они сначала: ага, вот предприятие должно быть… Направления деятельности и т. д.

Реплика из зала: Большие крупные промпроцессы.

Олег Захарчук: Да. Но самое интересное, что никогда не планируется вообще, а берется какой-то кусок проблемы, и начинают ее обрабатывать и т. д. — продажи, управление ресурсами… Сделали систему, запустили — там появились действия, в конце концов. Ну, где-то там кнопку нажали и т. д. А потом, значит, приняли решение расширять функционал. А для расширения функционала нужно опять сверху идти. Ага — у вас там в базе данных, или в модели, нет какого-то, скажем… Вы делали ERP...

Реплика из зала: А вы сможете на начальных этапах все действия предусмотреть? Не придется ли потом снова идти сверху и добавлять эти действия?

Олег Захарчук: Ну, тут уже неважно, как вы идете, сверху или снизу. Когда система выстроена, то есть скелет, вам уже неважно, откуда мысли появятся о действиях. Потому что смысл в чем — что вы выполняете, что-то делаете в системе всегда путем действий. То есть вы выполняете действия, которые вам рисует верх, в верхней части. Что значит действие? Например, выполняете действие по регистрации нового проекта. Это действие. Но вы выполняете его на самом нижнем...

Реплика из зала: А можно сказать, операция...

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

Реплика из зала: А отношения тогда, вот если на уровне действия, — это между кем?

Олег Захарчук: Отношения между действиями и действиями — когда есть иерархия. Отношения между действиями и результатами. То есть это вот эта стрелка, входные-выходные. Отношения есть между свойствами и результатом, и деятельностью, то есть действиями, задачами и т. д.

Реплика из зала: То есть на каждом уровне работает вот это трио?

Олег Захарчук: Да. На каждом уровне всё одинаково. Просто, я говорю: вот верхние уровни. Они были сделаны для того, чтобы было удобнее планировать. А когда вы выполняете, вы можете только смотреть на верхний уровень, вы там… Вы это действие выполняете для какого проекта?.. Для какого функционального подразделения? И т. д. Потому что это всё абстракции. Реальная вещь — это только действие. Вы же не можете пощупать проект сам по себе? Вы можете пощупать результат какой-то, который получился. Вы же не можете пощупать само по себе предприятие? Это только уровни группировки деятельности. И всё.

Реплика из зала: То есть ключевым у вас является действие?

Олег Захарчук: Действие, да. А есть еще один элемент, более ключевой: мы называем его квантом взаимодействия. Это вот элемент, через который мы строим всю деятельность.

Реплика из зала: Квант взаимодействия?

Олег Захарчук: Да. Потому что действие состоит из нескольких таких квантов. И в конце концов, в 2004 году у меня на заре, когда я был еще молодой-зеленый, была такая первая публикация по этой тематике, которая называлась «Квантовая теория менеджмента». Вот. Потом я перестал говорить о...

Реплика из зала: Книжка такая была, что-то похожее название...

Олег Захарчук: Нет, нет… Это была в свое время квантовая теория экономики и т. д., это не то. Я потом перестал говорить о квантах, потому что никто ничего не понимает в этом деле. Поэтому я начал искать другие, как говорится, образы описания этого всего — и пришел в конце концов к тому, что вот есть описание сверху, и есть описание снизу. Это более-менее уже понимается. А то, что еще ниже есть описания, я уже даже не говорю — но именно оно превращает эту систему в супербыструю и супергибкую.

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

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

Реплика из зала: И все заказчики в ней работают?

Олег Захарчук: Нет, не все. Кто хочет — работает, кто хочет — не работает. Потому что кто-то получает всякие документы по e-mail, а кому-то удобно в системе получать, чтобы не гонять...

Реплика из зала: Получается, что в настоящее время ваша система в большей степени направлена на научную деятельность, на поддержку научной деятельности?

Олег Захарчук: Да нет, есть система управления вагоноперевозками, система управления соревнованиями — это совсем не научные...

Реплика из зала: Вы можете показать одну, хоть какую-то из работающих систем — по вагонам, например?

Олег Захарчук: Давайте.

Реплика из зала: Вы же показали тесты какие-то, которые не отражают возможности...

Олег Захарчук: Да-да, сейчас. Я как раз именно имею тестовую штуку, в которой срез имеется прошлых годов, чтобы не раскрывать нынешнюю информацию… Сейчас покажем. Так, она была сделана еще с использование старой технологии...

Реплика из зала: Кто, вы сказали, пользователь по вагонам?

Олег Захарчук: Есть такое ПЦЦ РЕЙЛ (Petro Carbo Chem). Германский концерн, он имеет здесь филиал — поскольку он купил для себя здесь вагоны для перевозки химии. Ну, а филиал эти вагоны сдает еще для перевозки других вещей. То есть они сидят здесь, в Москве, и как раз управляют этими вагонами. У них порядка 700 своих вагонов, они еще в аренду берут столько же примерно.

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

См. видеозапись выступления Олега Захарчука на JSON.TV

Олег Захарчук, АСиС Софт: Новая парадигма построения цифровой экономики как экосистемы предприятий на базе единой цифровой платформы

Источник: Json.TV


13.02.2018 10:59

Комментарии

Нет комментариев. Ваш будет первым!