Меня зовут Алексеев Максим. Свою карьеру я начал системным администратором, затем стал программистом, перешел в аналитики, стал ведущим аналитиком, потом – функциональным архитектором, руководителем проекта. Теперь руковожу направлением производства в Инфостарт.Внедрение. Все это заняло примерно 12 лет.
Свою работу знаю, люблю – поделюсь информацией с вами и расскажу про наше направление более подробно.
Статусы и миссия направления
Направление Инфостарт.Внедрение относительно молодое – ему порядка трех лет. За эти три года мы как партнеры фирмы «1С уже получили ряд статусов – они перечислены на слайде.
Это показывает наш масштаб, ведь, чтобы получить эти статусы, недостаточно просто проработать такое количество времени на рынке.
Все, что сейчас выходит новое – 1С:Шина, 1С:Кабинет сотрудника – мы сразу туда “вгрызаемся”, активно это изучаем и стараемся применять на практике, чтобы достигать результатов, которые хочет получить заказчик. Все, что новое выходит, мы сразу погружаемся, нарабатываем опыт и стараемся быть первыми.
В процессе целеполагания мы сформулировали миссию нашего направления, на которую всегда ориентируемся при принятии решений. Потому что пока у компании нет цели, любые направления деятельности постоянно будут как “лебедь, рак и щука”.
Миссия нашего направления в компании Инфостарт звучит следующим образом:
Автоматизация бизнес-процессов заказчика для достижения целей бизнеса заказчика.
Это формулировка означает, что для нас автоматизация – это средство. Она никогда не является целью.
Сегодня была встреча, заказчик говорит: «Нам нужно построить новую целевую архитектуру». Мы говорим: «Зачем, какая цель бизнеса преследуется? В чем она выражается? Увеличивается доход, скорость, оборот, улучшается качество? Что вы хотите получить? Зачем вам новая архитектура?»
Многие бы согласились на этот проект: «Переход с разрозненной системы на единую систему ERP – это классно». Но мы, пока не докопаемся до сути, зачем это нужно заказчику, даже не приступим. В лучшем случае, сделаем обследование, чтобы разобраться в целях заказчика и донести до него эту информацию. Но основную работу мы не начнем.
При возникновении каких-то спорных вопросов мы будем руководствоваться этой миссией, будем именно здесь искать ответ на вопрос, как поступить в сложной ситуации: «Это помогает прийти к целям бизнеса? Если да, мы будем это делать».
Это очень важно, хочу акцентировать на этом внимание.
Технологии, которые мы используем
Для управления проектами внедрения мы у себя в команде используем технологии:
-
WaterFall;
-
Agile;
-
Scrum;
-
Бережливое производство (5 сигм).
Для процессов сопровождения мы устанавливаем и соблюдаем стандарты SLA.
Проектные технологии мы применяем не формально, они изучены нами достаточно глубоко – вы знаете, что Инфостарт периодически проводит обучение проектным технологиям. Все наши РП и функциональные архитекторы прошли обучение, и мы знаем эти технологии.
Перед тем, как стартовать любой проект, мы определяем, по какой технологии его оптимальнее всего выполнить.
У каждой технологии есть свои условия, свои исходные данные – когда ее целесообразно использовать, и когда она будет приносить результат. Поэтому мы сначала доносим до заказчика требования к этим технологиям.
Например, если функциональный заказчик к процессу внедрения в должной степени не привлекается, то Agile использовать нельзя. Понятно, что все хотят добиваться быстрого результата итерационно, но извините, это увеличивает требования к заказчику. Он должен быть постоянно погружен – должен быстро и оперативно решать открытые вопросы. Если этого происходит, это не Agile, и тем более не Scrum.
Поэтому выставляем требования заказчику, которые должны выполняться, чтобы эта технология работала, чтобы заказчик понимал, при каких условиях он достигнет того или иного результата.
Любую нашу работу мы пытаемся сделать максимально эффективно – в этом заключается суть технологии бережливого производства.
Если работа не приносит результата, мы от нее откажемся – зачем ее делать, если она никому не нужна? Если мы где-то видим лишние риски, то постараемся максимально их проработать, поэтому каждый проект – это обогащение наших знаний.
Приведу некоторые примеры.
На этапе сбора требований мы описываем бизнес-процессы по шаблонам.
Обычно на этапе сбора требований аналитик задает вопросы заказчику: «А как у вас происходит это? А как – то?» и т.д. Потом эта информация как-то структурируется и согласовывается с заказчиком в несколько итераций.
У нас это происходит по-другому – мы берем шаблон опросника и идем по шагам.
-
Во-первых, мы ничего не упускаем. Аналитик может забыть что-то спросить. При шаблоне он ничего не забудет.
-
Информация сразу структурируется. В принципе, и у заказчика тоже – он описывает не какой-то бизнес-процесс, который представляется ему в голове, а сразу видит все его шаги в таблице.
-
Сразу появляются термины – документ-источник, документ-приемник и т.д.
-
Сразу фиксируем, в каком виде данные переносятся.
-
Согласовываем формат отчетов, которыми будем производить контроль переноса и т.д.
Такой простой механизм как использование шаблонов очень сильно упрощает работу аналитика. И каждый проект в эти шаблоны привносит что-то новое, чтобы следующий проект был еще результативнее, еще успешнее.
Не все люди понимают информацию в таблицах, много визуалов, поэтому мы всегда рисуем для бизнес-процессов блок-схемы в нотации BPMN. Это достаточно простая нотация, ей легко обучиться. Ее же не только нам нужно знать, но и заказчику, чтобы понимать и согласовывать. И когда люди уже видят свои бизнес-процессы визуализированными, это проще воспринимается, быстрее согласовывается. Просто и эффективно. И это ускоряет процесс согласования, потому что мы можем свою работу сделать быстро (грубо говоря, за неделю), и три недели – процесс согласования. Чтобы его ускорить, нужно применять какие-то инструменты визуализации. И диаграммы BPMN – это отличный инструмент.
Третий показатель – мы собираем требования одновременно с моделированием процессов в программном продукте.
Когда с заказчика собираются требования и «хотелки», у него в голове формируется своя картинка, что он хочет. И когда на следующем этапе происходит моделирование в реальном продукте и заказчику говорят: «Это требование можно сделать по-другому, а это – таким образом, а здесь – разрыв». У него возникает вопрос: «Зачем вы спрашивали, как я хочу, если сейчас вы “притягиваете” меня к типовому продукту?» Это вызывает, как минимум, негатив, во-вторых, недопонимание, а в-третьих, увеличение сроков и бюджетов. Зачем?
Поэтому мы приняли для себя решение – на этапе сбора требований мы сразу моделируем бизнес-процесс и кусочно заказчику его показываем.
-
Во-первых, это дает привыкание к типовому продукту – заказчик сразу видит, как это будет реализовано. Он уже мыслит в парадигме продукта, не живет излишними фантазиями.
-
Мы уже понимаем ограничения – сразу видим разрывы и понимаем, как же от этих разрывов уйти типовой функциональностью. Потому что те, кто собирают требования – это, как правило, ведущий аналитик или функциональный архитектор – он сразу говорит: «это можно сделать так». И требования уже ложатся на типовой продукт. При этом процесс согласования гарантировано сокращается раза в три.
В каждой своей работе мы пытаемся что-то упростить и как можно быстрее добиться результата. Не смотрим на какие-то устоявшиеся шаблоны, стандарты, а смотрим, исходя из здравого смысла – как можно эту работу сделать эффективнее.
Концептуально: «Здравый смысл впереди планеты».
Также при разработке мы применяем технологии нагрузочного тестирования, сценарного тестирования и т.д.
Проектная деятельность в различных отраслях
Вот такими небольшими постоянными улучшениями мы за небольшой срок реализовали 25 крупных проектов. Это не полный перечень. Средняя динамика – это 5-7 проектов в год, условно, потому что если проект больше года, то его можно приплюсовать только в один какой-то год.
При этом мы работаем в разных отраслях. И я потом отдельно объясню, почему мы это можем делать.
Также хочу отметить, что у нас на каждом проекте всегда есть руководитель проекта и функциональный архитектор. Крупный проект без функционального архитектора “жить не может”. И мы гордимся нашими руководителями проекта и функциональными архитекторами, потому что в среднем у каждого из них 7 крупных проектов за спиной. Это уже такой багаж, который позволяет заходя на проект его выстроить правильно, не учиться на нем, а им управлять.
Мы знаем методики и инструменты, чтобы управлять проектом, но проект делает команда. И главное, что нам помогает делать проекты – это то, что мы очень ценим наших сотрудников.
Я привел на слайде цитату Доржи Валерьевича, основателя компании Инфостарт.
…главным в нашем Сообществе является личность человека, его знания и опыт!
Это является идеей всей компании, мы это ставим во главу.
Здесь расскажу подробнее. Когда человек приходит к нам, это уже получается не просто работник, это часть команды, к которому мы относимся очень трепетно.
-
После прохождения испытательного срока для сотрудника составляется маршрутная карта развития. Мы понимаем, к чему человек вообще стремится, чему он хочет научиться на работе, какие ему задачи интересно выполнять. Потому что то, что он будет делать, должно приносить удовольствие. Если он не хочет этим заниматься, он никогда не будет делать это хорошо. Поэтому первым делом мы спрашиваем: «Что ты хочешь делать? Что тебе интересно?». И потом он занимается задачами, которыми ему интересно заниматься. Потому что, если человек не хочет знать ДО, а хочет развивать производство, а мы его поставим на проект ДО, он никогда его не сделает хорошо. Поэтому мы спрашиваем у людей, в каком направлении они хотят развиться, что им интересно, и даем им эти задачи.
-
Второе – чтобы развиться, нужно обучение. Мы приветствуем обучение, закладываем в маршрутную карту, чтобы человек проходил обучение. Это и наша инициатива, и инициатива сотрудника, но это обязательно. Составляется план на весь год, в течение года сотрудник постоянно проходит это обучение, мы постоянно повышаем квалификацию – без этого в наши дни просто никуда.
-
Дальше – мы не допускаем хронических перегрузок. При планировании смотрим, чтобы человек никогда не работал по 10-12 часов в день. Понятно, что переработки случаются, особенно, на этапе запуска – краткосрочно это допустимо. Но мы прекрасно понимаем, что если человек долгое время работает по 10 часов в день, потом он перестает работать – он только делает вид, что работает. Поэтому перегрузки не допускаются.
Эти правила – простые. Но при этих правилах человек хочет работать.
Помимо всего прочего, что я сказал, мы всегда ищем людей, которые нацелены на результат. Не на процесс, не на показушность, а именно на то, чтобы приносить бизнесу результат с помощью автоматизации.
Все решения лежат на поверхности – если вы хотите понять, как лучше поступить, спросите, поймите и сделайте. Здесь такой же принцип.
На этом слайде перечислены проекты команды направления Инфостарт.Внедрение – я выбрал далеко не все проекты, только самые крупные. Здесь по названиям видно, что мы не просто внедрили систему ERP на организацию из 10 человек с простыми бизнес-процессами, все это – действительно крупные компании.
Все эти проекты реализовала наша команда, придерживаясь приведенных ранее принципов. Это – наша гордость.
Работа с партнерами
Ранее я уже говорил, что мы работаем над проектами в разных отраслях. Такого часто не могут себе позволить другие компании, но у Инфостарта достаточно большое сообщество, поэтому к нам на сотрудничество могут приходить разные запросы.
Эти проекты, помимо нашей внутренней команды, нам помогает реализовывать партнерство. Его можно условно разделить на две части
-
Первое – это когда мы кого-то привлекаем.
-
Второе – это когда нас куда-то привлекают.
Когда мы привлекаем внешних специалистов, это могут быть:
-
либо физические лица, которые хотят с нами работать;
-
либо юридические лица – уже сформированные команды, которые на чем-то специализируются (например, они могут специализироваться на интеграции, на переносе остатков и т.д.). Поскольку мы с ними уже сработались, мы добавляем их в команды с нашим РП и функциональным архитектором.
Для заказчика команда исполнителя остается одна – привлеченные специалисты выступают от нашей стороны, и мы уже выстраиваем с ними работу в команде.
Таким образом, если у нас нет компетенции в какой-то отрасли, например, в автоматизации молокозаводов – но мы уже автоматизировали мясное производство, промышленность, еще что-то, но к нам пришел молокозавод – тогда мы можем призвать сообщество и найти команду с успешным опытом.
При входе мы этот опыт проверяем – первые задачи даем относительно небольшие, чтобы все-таки убедиться, что команда справится. И потом уже привлекаем их на серьезные проекты.
Как мы проверяем?
-
Первый этап – это убеждаемся, что человек или команда точно технически знают, о чем говорят.
-
Например, при проверке аналитика нам важно, насколько хорошо он знает продукт – какие у него теоретические и практические знания, насколько он умеет моделировать бизнес-процессы.
-
Если он программист – даем ему задание. Если он не хочет это задание делать, значит, он не пройдет. Его никто не заставляет.
-
-
Второй этап – убеждаемся, что человек нацелен на результат, что главный его стимул работы – не финансовый. Он должен быть не процессником, он должен хотеть получить результат.
И только когда мы убеждаемся, что человек достаточной квалификации и действительно правильно смотивирован, принимаем его в команду. Мы потратим много времени на то, чтобы его проверить, но мы будем уверены в процессе работы. Вот так мы встраиваем работу пришедших специалистов в свой команде и совместно работаем.
Таким же образом к нам обращаются и другие компании, которые взяли крупный проект, и им на него не хватает людей. Они предлагают нам работать с ними на проекте совместно.
Мы этот проект анализируем – смотрим, чем мы можем помочь, разбираем, есть ли у проекта цель, прояснили ли ее. Если мы видим, что с проектом все нормально, и там действительно нужны только наши компетенции, мы, конечно, будем сотрудничать.
Т.е. и мы с кем-то сотрудничаем, и с нами сотрудничают.
Почему с нами интересно работать?
Сотрудничая с Инфостарт.Внедрение, вы получите:
Опыт работы по разным технологиям. Люди часто устают от работы на крупных проектах, где длительность превышает полгода: проект сначала моделируют, потом – пишут ТЗ, потом – разрабатывают, потом все это с болью запускается (если одним блоком) и т.д.
У нас они могут работать в маленькой команде и быстро получать результаты по Agile. Т.е. если человек действительно проходит все наши проверки, мы убеждаемся в том, что он специалист, то добавляем его в Agile-команду, где каждые две недели – новая итерация. Т.е. человек каждые две недели видит результат своей работы. Он счастлив от своей работы. Все просто.
Или наоборот – человек работал в небольшом отделе, а теперь он хочет поучаствовать в больших проектах. Не вопрос. Если он нам подходит – у нас есть большие проекты.
Опыт работы в большой команде. Некоторых людей мотивирует общение с другими людьми по работе. Это такой драйв, когда ты ежедневно собираешься с людьми и каждый рассказывает: «Я сделал то», другой: «Я сделал другое». А третий говорит: «Я не сделал, у меня такая проблема». И тут начинается мозгоштурм, как проблему решить. Это людей очень сильно стимулирует. Для некоторых это – основной стимул работы. Они целый день работают, чтобы на следующий день сказать: «Представляете, у меня получилось!». И все, он счастлив. У нас есть возможность получить это счастье.
Выполнение интересных/сложных задач. Некоторые работают на сопровождении. Изо дня в день – печатные формы, механизмы контроля заполнения. Душа требует какую-то сложную задачу? Welcome. У нас точно нет дефицита сложных задач, где до того, как начать что-то реализовывать, нужно все проанализировать и спланировать наиболее грамотную реализацию.
Участие во внедрении различных конфигураций. Часто человек работает с какой-то небольшой конфигурацией – например, с «Управление торговлей», но хочет развиваться, хочет знать другие конфигурации. Пожалуйста. Если человек, например, хорошо знает «Управление торговлей», мы его добавляем в проект по автоматизации конфигурации «Комплексная автоматизация». Он там изучит дополнительно производство или бюджетирование, а потом, если захочет, перейдет на проект по ERP. В общем, опять же, составляется карта развития, и человек может узнавать новые конфигурации. Тут есть, куда людям расти. Поэтому, кроме того, что эта работа всегда оплачивается, людям интересно с нами работать и по другим поводам.
Как передаются задачи?
Есть золотое правило:
Все, что сделано, должно быть оплачено. Все что оплачено, должно быть сделано.
Перед тем, как любая работа передается исполнителю – либо команде, либо другой компании, она строго оценивается и определяются ее рамки.
Если в ходе выполнения задачи исходные данные как-то поменялись – поменяется оценка и стоимость. Это все учитывается.
Но перед тем, как начать реализовывать задачу, человек должен четко понимать ее ожидаемый результат, стоимость и сроки, за которые он отвечает.
Поэтому, как бы это тяжело ни было, мы всегда стараемся разобрать задачу детально, чтобы понимать, к какому результату нужно стремиться.
Станьте частью команды Инфостарт.Внедрение!
Если вас заинтересовало сотрудничество с нами, заполните анкету https://forms.gle/UwGDb2AnWkGWnTUz5.
Обозначьте в анкете свои компетенции, возможности, интересы и устремления.
Мы проанализируем ваши ответы, и, если мы друг другу подходим, то создадим возможность для реализации ваших профессиональных навыков.
Уверен, что мы сработаемся, и вам будет с нами интересно!
|
Статья написана по итогам доклада (видео), прочитанного на конференции Infostart Event 2022. Больше статей можно прочитать здесь. Приглашаем на мероприятия Инфостарта 2023 года:
|
