Юрий Блощинский, «КСК ТЕХНОЛОГИИ»: Мы обгоним глобальных ИТ-лидеров за счет того, что идеи наших продуктов — на шаг впереди

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

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

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

Юрий Блощинский: Нет. Во-первых, регламент — это очень жесткая вещь. Яркий пример — это полноценные госуслуги как система исполнения регламентов. Возьмем, к примеру, наши проекты с Минстроем России. Они охватывают процессы, связанные с выдачей разрешений на строительство, на ввод в эксплуатацию, с аттестацией и т.д. И эти регламенты, действительно, очень жесткие. Например, выдача разрешения на строительство — это пять рабочих дней, даже если речь идет о таком сооружении как Крымский мост. Представляете, как нужно организовать работу со всей документацией, результатами экспертиз и т.д., чтобы не сорвать выдачу разрешений на строительство?

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

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

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

Юрий Блощинский: По моим оценкам, в целом, проектный подход сегодня в России очень плохо развит. Мы как компания «КСК ТЕХНОЛОГИИ» накопили большой опыт выполнения проектов информатизации для крупных заказчиков и видим, что фактически проектного управления у наших заказчиков либо нет совсем, либо оно используется очень слабо. Как следствие, отсутствует дисциплина командной работы. И вот что важно: есть большая потребность в этом, причем, со стороны именно заказчиков. Почему? Все просто: заказчик хочет получать то, что он заказывает, точно в срок и иметь возможность управления. Судите сами. Практически не существует ни одной корпоративной системы с жизненным циклом в один год. Внедрение любой информационной системы, с точки зрения ее использования, — это проект лет на десять, ведь вначале системы создаются, затем сопровождаются, потом модернизируются, потом развиваются. Так что полноценный цикл жизни корпоративной системы составляет в среднем 10 лет.

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

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

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

Юрий Блощинский: Если положить рядом план проекта со стороны заказчика и план проекта со стороны подрядчика, то это будут два разных плана. А заказчику важно, чтобы они были синхронизированы. То есть в тот момент, когда подрядчик исполняет тот или иной этап проекта, заказчик хочет понимать, в каком состоянии находятся работы именно сейчас. Где это можно посмотреть? Как реально происходит исполнение работ? Вот в ответ на эту потребность, которая буквально выстрадана заказчиками (я не утрирую — в ней реально нуждаются все крупные организации, которые имеют длинные проектные циклы), и создана наша система КСК.Проекты.

Юрий Блощинский: Поскольку «КСК ТЕХНОЛОГИИ» - компания полного цикла разработки систем, во всех проектах в обязательном порядке работает две команды: команда исследований и команда реализации. Исследовательский блок необходим, потому что, работая с заказчиком, мы адаптируем большое количество технологий, методологий, ведь на практике реализация любого проекта не попадает под «зонтик» какой-то одной конкретной методологии. Возглавляет команду исследований человек, которого сегодня модно называть product owner, то есть владелец продукта (создаваемая система — в данном случае и есть продукт). Фактически это бизнес-команда, которая решает конструкторскую задачу — разрабатывает облик продукта: собирает требования представителей заказчика, изучает рынок, осуществляет всю консалтинговую поддержку, то есть полностью моделирует систему, которую мы создаем.

Юрий Блощинский: Это полностью прорисованная система в картинках и с работающими интерфейсами. Фактически заказчик смотрит на экран, видит кликабельный макет и понимает: да, это именно то, что мне надо. Знаете, многие люди даже обманываются: у вас же уже система готова! Нет, это еще не готовая система. Конечно, труда в нее вкладывается немало. Но все равно это быстрее и дешевле, чем создавать такую систему в коде, где и цена ошибки с последующей переработкой кода тоже несопоставимо выше.

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

Юрий Блощинский: Да, есть всем известная организация Project Management Institute (PMI). Она в своих рекомендациях на очень высоком уровне описывает, что должен содержать проект. И если ранее PMI (в PMBOK) проповедовал процессный подход к управлению проектами, то в последней 7-й версии в связи со стремительным развитием Agile PMI перешел на концепцию гибридного управления, включающую прогнозное и адаптивное управление. Вылилось это в 12 принципов управления проектами и 8 областей эффективности (знаний). Смена концепции проектного управления дает заказчикам, с одной стороны, свободу в использовании моделей управления проектами, с другой, — размывает строгость и определенность в управлении. При этом, на практике реальные процессы никуда не уходят. Все это говорит о том, что проблема управления проектами для заказчиков становится еще сложнее.

Каким образом заказчик управляет в настоящий момент проектами с большими жизненными циклами с точки зрения использования технологий? — Как правило, методом «склейки»: для стратегического управления портфелями проектов и программ используются доработанные средства бюджетирования (инвестирования); для планирования работ — например, Microsoft Project; для коммуникаций — современные мессенджеры и ВКС; для организации группового исполнения работ (задач) — трекеры, например, Atlassian Jira; для знаний — wiki, например, Atlassian Confluence. Безусловно, по отраслям набор средств может быть различным, но подход остается единым.

Налицо явно выраженных три уровня управления:

1. Стратегическое управление, что соответствует управлению портфелем проектов.
2. Тактическое управление, что соответствует макроуправлению проектом.
3. Оперативное управление, что соответствует управлению исполнением проекта его командой.

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

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

В КСК.Проекты мы создали для каждого уровня свои модули или заложили соответствующие функции. Так удается реализовать в комплексе всю систему управления и исполнения: от уровня управления портфелем через управление проектом и до нижнего уровня трекера, где идет рутинная реализация огромного количества задач.

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

Юрий Блощинский: Когда мы создавали модуль трекера для первой версии КСК.Проекты, мы ориентировались на ИТ-компании. Но поскольку продукт реализует, по сути, возможность детализации большого объема задач, он может применяться и в других отраслях. Приведу пример. Один из наших клиентов — крупный федеральный орган власти, для которого мы развиваем и сопровождаем несколько систем на протяжении многих лет. Если заказчику нужно дать нам заявку на какое-то изменение, то для формирования этой заявки требуется запустить в среднем 10 работ. А в течение года поступает приблизительно 40 заявок. Получается, что если эти 10 работ просто положить в систему управления проектом, они сгенерят перечень из 400 задач, которыми управлять невозможно на тактическом уровне. При использовании КСК.Проекты все поступающие заявки стоят в системе, запускаются на выполнение и переходят в трекер.

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

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

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

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

Юрий Блощинский: Мы поставили перед собой амбициозную задачу – научиться управлять большим проектом с позиции «точно в срок». Даже если речь идет о применении гибких методологий Agile-Scrum в ИТ-компаниях. Почему это важно?

У ИТ-рынка есть большая проблема с выдерживанием сроков. Большинство айтишных проектов идут по одной из двух схем. Либо это a’la инвестиционный проект без временных границ — пока не будет готов весь функционал, продукт не будет выведен на рынок. Либо это вариант госконтракта, когда к концу года надо представить работающую систему, а она не готова, и возникают договоренности о доработке системы в следующем году, например, в рамках гарантийного сопровождения и т. д. В целом, эти цепочки работ с перенесенными сроками очень сильно тормозят развитие рынка. И наш подход по-крупному заключается в том, чтобы между проектом и трекером реализовать такую логическую связь, при которой изменения, вносимые на высоком уровне проекта, отражались в трекере, где люди работают в Scrum-командах над задачами из бэклога. Например, руководство может внести изменения в требования к проекту, скажем, уменьшить срок исполнения проекта на 20%, и увидеть, на какой объем завершенных работ можно будет рассчитывать.

Задача очень нетривиальная. Но она очень нужна и бизнесу, и государству.

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

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

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

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

Юрий Блощинский: Очевидно, что при создании такого продукта мы учитываем все популярные тенденции на рынке. Поэтому ключевой режим работы с продуктом — классический SaaS (сервис как услуга). Любой человек может зайти на наш сайт, оформить подписку в качестве нового пользователя и получить свою собственную систему управления проектом.

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

А еще в продукте реализованы механизмы Low-code/No-code. По нашим представлениям, они должны быть, прежде всего, дополнением платформы там, где бизнес, действительно, нуждается в гибкости. Но при этом мы внедряем эти механизмы очень осторожно для того, чтобы не нарушить главные принципы: корпоративности, безопасности и т.д.

Кроме того, мы можем поставить заказчику коробочное решение. Конечно, оно относится к классу сложных продуктов, требующих внедрения. Это — естественная процедура. Ведь даже для внедрения более простого продукта Jira требуется затратить немало времени на изучение концепции продукта, механизма выстраивания процесса и т.д. И еще, помимо готового коробочного решения, заказчик получает наборы сервисов. Можно сказать, что их наличие производит небольшую внутреннюю революцию у заказчика.

Юрий Блощинский: Вы знаете, что на западном рынке сегодня наблюдается мощное движение от публичных облаков в сторону закрытости корпораций? Главный выразитель этой тенденции — корпорация Microsoft. Она сегодня стала поставлять свое облако Azure внутрь корпораций. И это стало настоящей революцией на рынке. Представьте себе: крупная корпорация отказывается от пользования публичными облачными услугами Azure, потому что не желает передавать во внешнее облако свои корпоративные данные. И Microsoft отвечает: тогда мы идем к вам, и всю инфраструктуру Azure со всеми нужными сервисами развертывает внутри корпорации.

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

Так, мы создаем свой сервис «Диск». Ведь организации нужно работать с файлами в закрытом контуре, и никакой «Яндекс.Диск» тут не подойдет. Еще мы добавили сервис внутреннего чата.

Юрий Блощинский: Система управления бизнес-процессом ведет исполнение работ по некоторому маршруту. Но через эту систему невозможно проводить мозговые штурмы! А что делать, если нужно собрать коллектив (вспомните Scrum!) и обсудить, как именно выполнить ту или иную задачу? Вот для этого нужен внутренний чат: сотрудники собрались, провели обсуждение, приняли некоторые решения, выдали поручения, а обсуждение запись разговора сохранилось в системе в виде документа, причем, прикрепленного именно к той зоне проекта, где это происходило. То есть чат всегда привязан к определенной точке проекта. И нет никаких ограничений на количество этих групповых чатов: руководитель проекта формирует столько групп для чатов, сколько вопросов нужно обсудить и принять решение, согласованное командой.

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

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

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

Так, увлекательная идея создания универсальных Low-code платформ разработки к настоящему времени в мире корпоративных систем сильно поблекла. Пример. Фактически есть мировой лидер в Low-code разработке процессных систем — американская компания Pega Systems. За годы своего развития своей Low-code платформы она вложила в продукт колоссальные деньги и получила дорогое решение, которое по уровню сложности сегодня превосходит программирование на Java, специалисты-«пегаводы» — дефицитные и очень дорогие. Рынок уже не испытывает оптимизма по поводу будущего компании: капитализация Pega сегодня немного превышает 4 млрд. долл., в то время как компания Atlassian со своими двумя удачными продуктами Jira и Confluence оценивается более 50 млрд. долл.

А теперь посмотрите на Microsoft. Компания занимается технологиями Low-code практически все время, сколько существует. ПО SharePoint, Power Apps — это все, по сути, Low-code. Но корпорация сама предупреждает: не создавайте ничего серьезного в SharePoint, потому что при переходе на следующую версию пользовательские доработки могут не сохраниться. Основное предназначение Power Apps — закрыть «дыры», которые оказались незакрыты специализированными продуктами (специализированный продукт всегда будет опережать по качеству проработки любые Low-code решения).

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

Юрий Блощинский: На оба рынка. При этом мы разделяем с точки зрения проектного управления рынки заказчиков и исполнителей: рынок заказчиков — это «голубой океан» (не сильно занятый), а исполнителей — «алый» (конкурентный).

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

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

Стоит упомянуть также российские системы, которые для нас являются не столько конкурентами, сколько партнерами. Например, для строительной отрасли разработаны продукты управления капитальным строительством, которые базируются на CAD/CAM-системах и порождают цепочки управления в русле решений PLM (Product Lifecycle Management), предназначенных для предприятий промышленности. Но при этом у предприятий возникают большие проблемы с классическим управлением проектами в связке с указанными технологиями. Есть множество проектов, не связанных непосредственно с САПР-продукцией. Здесь есть почва для внедрений нашей системы.

Юрий Блощинский: Скажу так: раскрученный маховик Microsoft вряд ли удастся догнать, потому что в продукты корпорации вложено огромное количество человеко-лет высококвалифицированных исследователей и разработчиков и колоссальные финансовые инвестиции. Опередить условный Microsoft можно только, предложив рынку что-то, сделанное на том же уровне или лучше за счет совсем другого подхода. То есть за счет иной идеи продукта. Для меня как человека, связанного когда-то с авиационно-космической темой, это не вызывает удивления: идеи, которые реализовывались во времена Советского Союза, позволяли создавать самолеты, перед которыми мировые конкуренты «снимали шляпы». Это достигалось за счет уникальной конструкторской мысли.

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