Зачем быть инженером по внедрению
Четыре года назад я увидел вакансию инженера по внедрению. Из словосочетания «инженер по внедрению» я мог сделать только очень общий вывод, чем занимается этот специалист. Но т.к. в требованиях было указано знание C# и необходимость писать код, я решил попробовать себя в этой роли. Звезды совпали удачно, и меня позвали на работу.
Как выяснилось в дальнейшем, понятие «инженер по внедрению» так же, как «программист», объединяет в себе очень много разных, но родственных вещей. Все внедренцы так или иначе устанавливают и настраивают «нечто» под требования конечного заказчика. Но областей внедрения так много, что специфику каждой расписать мне кажется невозможным.
В этой статье я постараюсь описать, почему вам может быть интересно стать инженером по внедрению. Если быть точнее, то инженером по внедрению какого-либо ПО, потому что сфера внедрения «железа» для меня — темный лес. Обращаю также внимание на то, что мой личный опыт может быть довольно однобоким.
1. Человек-оркестр
Это, пожалуй, главная причина. Если вы не чувствуете в себе стремления становиться гуру какой-то узкой специфики, то внедренец — это судьба для вас. Я работаю с людьми, которые в определенный момент поняли, что погружаться, например, в тонкости MS SQL до уровня MCSE им не интересно (в этом месте можете подставить любую технологию и «джедайский» уровень для нее). И это не «лень», а осознанный выбор.
Для инженера важно кроме знания внедряемого продукта обладать довольно обширными познаниями во всех соприкасающихся областях. А также во всех потенциально соприкасающихся областях. У нас, например, помимо максимального владения внедряемой программой, обязательным является хороший уровень владения C# и T-SQL, базовый навык администрирования серверной винды и знание всякой «экзотики» вроде XSLT и VBS. А пожеланиями к тому, что инженер может знать, можно исписать рулон туалетной бумаги в 54 метра: это и 1С, и Adobe FlexiCapture, и InfoPath, и знание любых ERP, СЭД и так далее, и тому подобное.
2. Сам себе режиссер
В небольших проектах, зачастую, всю техническую часть выполняет один инженер. Он и продумывает архитектуру решения, и настраивает его, и пишет код, и проводит сдачу техническим специалистам заказчика. В больших проектах инженеру отдается модуль, в котором он, опять-таки, является сам-себе-режиссером. Т.е. исключены ситуации, когда вы все сделали хорошо, а ваш коллега накосячил, из-за чего не приняли всю работу, ну или вам досталась ужасная архитектура, с которой вам приходится мириться и пилить под нее костыли. Все сам и только сам.
3. Пятилетку за два года
Внедрение чаще всего идет по стандартному циклу: собрали требования, сделали, сдали, начинай сначала. А каждый этап этого цикла довольно короткий, поэтому исключены ситуации, когда вы можете пилить какой-то модуль, и лишь через года два увидеть его реальное использование. Здесь результат своей работы, а также его применение в жизни можно ощутить через 3 месяца после старта работ. Или вы все круто и удобно сделали, и заказчик этим пользуется, или ваша работа была бессмысленна. Для любителей быстрого результата то, что надо.
4. Живые люди
Это довольно спорный момент для айтишников, которых все привыкли считать замкнутыми и необщительными людьми. В реальности в айти-сфере работает куча людей, которые могут и любят общаться с заказчиком. В случае с внедренцем такая потребность тоже будет удовлетворена: на этапе сдачи работ вам придется общаться с ИТ-персоналом заказчика, объясняя, что же такое вы им понаделали, и как это дальше поддерживать. А также бегать по конечным пользователям, помогая им справляться с ошибками, которые вы допустили на этапе разработки (ну или просто объяснять, почему нажатие кнопки «Создать задание» приводит к созданию задания). Возможно это звучит не так уж весело, но в реальности общение с пользователями довольно интересно.
Из этого же пункта вырастает следующий:
5. «Сам испек, сам и кушай»
Вы получаете отзыв о результатах своей работы из первых рук и, что самое главное, можете на него повлиять. Т.е. достаточно пользователю показать какую-либо удобную фичу, или поправить какую-то неудобную функциональность на его глазах, чтобы получить «друга», защищающего вашу программу перед руководством. Что положительно скажется на дальнейших проектах.
6. Все дороги открыты
Последний пункт, который отчасти противоречит первому: из-за того, что вы являетесь полу-специалистом в большом количестве разных областей, в любой момент, когда вам надоест заниматься внедрением конкретного продукта, вы можете выбрать для себя путь узкой спецификации в одной технологии, технического менеджмента (тим-лид) или обычного менеджмента (руководитель проектов). Знаний для старта у вас будет достаточно, а опыт проектой работы довольно высоко ценится на рынке, да и вашим непосредственным руководителем тоже.
Пока, пожалуй, все. Я постарался кратко написать, почему эта работа может заинтересовать кого-то. И если в голове какого-нибудь студента после этой статьи появилась мысль попробовать себя в качестве инженера по внедрению, то я буду очень рад.
Если остались вопросы, пишите, постараюсь ответить.
- инженер по внедрению
- карьера в it-индустрии
Кто должен внедрять в компании новый программный продукт
Перед вами стоит задача: адаптировать стандартное IT-решение к потребностям своего бизнеса. С чего начать внедрение программного продукта, чтобы заставить его эффективно работать?
Уже давно вы мечтали приобрести программный продукт, который решит многие проблемы вашего бизнеса. Вы работаете достаточно долгое время на рынке, есть успехи, вы расширяетесь, но чего-то не хватает. Эффективной аналитики, правильного прогнозирования, качественного контроля. И вот спустя какое-то время вы нашли программный продукт, провели тендер, сравнили аналоги и выбрали то, что вам «по карману».
Если вы собственник, то спланировав покупку, вы захотите, чтобы выбранная вами программа окупилась в короткий срок, и не стала очередным «дорогим калькулятором» для ваших сотрудников. Для этого, как только вы приняли решение о приобретении, стоит задуматься о процессе внедрения. Заметьте, не после покупки, а до того, как вы только приняли решение и спланировали бюджет.
Самое первое, о чем вы должны задуматься – это о «движке» процесса внедрения. Я называю «движком» специалиста, который будет владельцем всех процессов, связанных с внедрением приобретенного программного продукта. Этим специалистом должен быть не просто выбранным вами по занимаемой должности (например, начальник IT-отдела), или не сильно занятый в данный момент сотрудник, который более-менее понимает задачи, для приобретения которых вы купили программу. Во-первых, это должен быть специалист, который имеет опыт именно внедрения программ. Во-вторых, он должен понимать проблемы, которые должна решить данная программа. Он должен знать обо всех процессах внутри компании, которые связанны с решением задач при покупке программы. И конечно же, он должен «гореть». Под словом «гореть» я подразумеваю, что он должен как никто другой в компании понимать, что программа – это лучшее решение поставленных перед ним задач. Что при правильном внедрении компания получит эффективный инструмент, который облегчит работу многих, и в результате компания поднимется на ступень выше в своем развитии. И свой огонь этот внедренец должен уметь передавать не только топ-менеджерам, но и всем в компании.
Хочу оградить вас от распространенной ошибки, которую совершают собственники или топ-менеджеры, выбрав таким человеком IT-специалиста. Не спорю, любой IT-специалист разбирается в программах, знает все связи в них, сможет прописать дополнительный код. И все мы привыкли, что если IT-отдел нашел программный продукт, был ответственным за его приобретение и после покупки был связующим звеном в настройках связей, то и внедрением должен заниматься IT-специалист. Это неправильно!
Выбранный вами внедренец должен быть связующим звеном между разработчиком программы, IT-отделом и заказчиком программы внутри компании (в моем случае это, например, коммерческий отдел). И простыми словами должен понимать нужды заказчика программного продукта (коммерческого отдела), а после этого суметь правильно написать техническое задание для IT-отдела и разработчика программы. На своем опыте скажу, более правильно будет распределить задачу написания технического задания специалисту по внедрению. Расскажу на примере, почему.
Если написание технического задания на начальной стадии поручить IT-отделу, то специалисты отдела не всегда до конца понимают потребности коммерческого отдела. Например, какие показатели должны отображаться в планируемой программе, и на основании каких экономических формул данные показатели рассчитываются. Если написанием технического задания займется коммерческий отдел, то грубо говоря, разработчики, получив такое задание, будут переспрашивать по десять раз, пока не поймут, что хотят специалисты коммерческого отдела от программы в будущем. Ну и конечно, самый большой плюс в пользу написания технического задания специалистом по внедрению, который не относится ни к IT-отделу, ни к коммерческому подразделению, заключается в следующем. Ваш будущий специалист по внедрению, после того, как вы купите программу и обучите всех пользователей программы, будет ее сопровождать. И в процессе работы с программой у вас появятся потребности в новых доработках или функционалах программы. В таком случае специалист по внедрению, который знает программу с точки зрения ее функционала (связей внутри программы), а также экономические аспекты данной программы, без труда сможет написать новое техническое задание по доработке программы. Вы экономите время и деньги!
В заключение данной статьи скажу о том, что самый легкий путь для собственника или топ-менеджера – это обратиться к разработчикам приобретенной вами программы для ее внедрения. Во-первых, у них за плечами многолетний опыт, во-вторых, они знают все нюансы в данной программе, и изначально понимают, для чего она была придумана (ведь они ее разработали). Но чаще всего стоимость внедрения программного продукта от компании разработчика равна стоимости самой программы. Если вы купили программу за один миллион рублей, то тратить на ее внедрение еще один миллион рублей, по-моему, невыгодно. Лучше впоследствии придержать этот миллион на доработку программы, приобретения дополнительных функционалов.
Ищите «движки» внутри своей компании, они обязательно найдутся. Ведь сотрудники в курсе многих бизнес-процессов, и вы сэкономите время. Ведь специалист от компании разработчика в начале внедрения потратит минимум один месяц, чтобы изучить все ваши бизнес-процессы, изучить связи между отделами, и самое главное – выявить бизнес-цели, которые вы хотите достичь после приобретения программного продукта. А ваш сотрудник, работающий не один год в компании, без труда, в короткие сроки и эффективно справится с этими задачами. Но если у вас с персоналом совсем туго, то попробуйте поискать такого специалиста у ваших партнеров и одолжить его на время внедрения у них.
Как получить полный бесплатный доступ к публикации?
- Авторизоваться или зарегистрироваться на сайте
- Подписаться на:
- рассылку «Продажи и Маркетинг»
Кто занимается внедрением по
ERP-консультант (консультант по внедрению ERP-систем) — универсальный специалист. Он занимается внедрением и отладкой систем планирования предприятия. Работа этого специалиста включает также создание, изменение и сопровождение информационных систем компании, автоматизацию задач предприятия (учет, анализ, контроль, планирование, реализацию товаров и т.д.). ERP-консультант должен хорошо разбираться в информационных системах, бизнес-процессах, иметь навыки управления проектной командой, управления проектами, понимать методологию внедрения ERP-системы, иметь представления о системах Navision, Axapta, ORACLE, BAAN, Scala, Platinum, SUN System, SAP и базах данных ORACLE, MSSQL, DB2.
Основные обязанности:
- Техническая поддержка процессов ;
- Помимо внедрения информационной системы в структуру организации необходимо также осуществлять своевременную техническую поддержки для ее правильной эксплуатации, а именно должно быть осуществлено: проведение работ по инсталляции ИС;
- техническое сопровождение в процессе эксплуатации ИС;
- кодирование программного обеспечения ИС в рамках поставленного задания;
- формирование технической документации и инструкций по эксплуатации ;
- Для того чтобы автоматизированная информационная система успешно существовала, требуется ряд специальных обеспечивающих систем и средств на всех этапах ее жизненного цикла, поэтому важно, чтобы ERP-консультант должен рассмотреть все эти средства в комплексе ;
- Сюда входит: участие в проведении переговоров с заказчиком, выяснение его первоначальных требований к ИС, взаимодействие с заказчиком в процессе реализации проекта;
- сбор детальной информации для формализации предметной области проекта и требований пользователей заказчика;
- описание устройства и информационного обеспечения бизнес-процессов предприятия заказчика;
- описание реализации бизнес-процессов предприятия заказчика в ИС;
- составление технического задания на разработку ИС;
- разработка концепции будущей ИС заказчика;
- управление командой исполнителей проекта ИС;
- управление расписанием проекта;
- программирование в ходе разработки ИС;
- интеграция ИС с аппаратно-программными комплексами заказчика;
- проведение внутреннего тестирования ИС;
- настройка параметров ИС и тестирование результатов настройки;
- участие в экспертном тестировании ИС на этапе опытной эксплуатации;
- устранение замечания пользователей ИС по результатам опытной эксплуатации ;
- Для того, чтобы после внедрения информационной системы неопытный пользователь мог правильно и в полной мере ею пользоваться, ERP-консультант должен провести и инструктаж с сотрудниками компании и объяснить, из каких этапов состоит работа с системой, а также помочь составить пользовательский опыт ;
- Именно поэтому в круг обязанностей ERP-специалиста также входит: консультация пользователей информационной системы;
- обучение пользователей работе с ИС;
- подготовка демонстрационных баз ИС (презентационных материалов);
- составления отчетности по результатам проведенного обучения.
Требования к индивидуальным особенностям специалиста
- Аналитические способности;
- организаторские способности;
- умение просчитывать варианты развития событий на несколько шагов вперед;
- ответственность;
- стрессоустойчивость;
- скрупулёзность;
- коммуникабельность;
- умение расположить к себе собеседника;
- умение убеждать и быть услышанным;
- умение применять ситуационную этику;
Требования к профессиональной подготовке
- Среднее профессиональное или высшее образование (бакалавриат, специалитет, магистратура) – в зависимости от уровня квалификации ;
- Знание основ архитектуры, устройства и функционирования современных ИС;
- Знание основ современных систем управления, хранения и анализа баз данных;
- Знание основ программирования (языков программирования);
- Знание современных методик тестирования ИС;
- Знание основ информационной безопасности предприятия, современных стандартов автоматизации процессов (например, CRM, MRP, ERP, ITIL, ITSM и пр.);
- Плюсом будет ориентирование в процессах экономического учета и отчетности предприятия (бухгалтерский, налоговый, финансовый, управленческий учет), а также знание основ менеджмента;
- Навык работы с различного рода информацией: сбор информации, ее обработка и анализ;
- Умение выстроить эффективные коммуникации в деловом взаимодействии с коллегами, заказчиками;
- Умение читать проектную документацию.
Кто занимается внедрением по
1.4.4. Внедрение системы программного обеспечения
1.4.4. Внедрение системы программного обеспечения
Протестированный программный продукт должен быть внедрен. Внедрение системы охватывает весь процесс внедрения программного обеспечения, перенос данных из старой системы, обучение пользователей и системных администраторов, поддержка пользователей системы и внесение исправлений для устранения ошибок, обнаруженных после развертывания.
Внедрение программного продукта содержит ряд различных шагов. Точный процесс отсутствует, поскольку обстановка, в которой программное обеспечение внедряется, существенно варьируется у различных клиентов. Однако, как правило, необходимы следующие виды деятельности:
- развертывание программного продукта, т. е. инсталлирование (установка) на «железо». Для более сложных, распределенных систем полезны UML-схемы развертывания, которые описывают локализацию программного обеспечения на различные аппаратные узлы, в том числе:
- Выпуск (release). Выпуск следует за процессом разработки. Он включает в себя все виды деятельности, подготавливающие систему для ассемблирования (перевод в машинный код) и передачу клиенту. В ходе этой деятельности определяют также ресурсы, необходимые для работы у клиента.
- Установка (инсталлирование) и активизацияпрограммного обеспечения — запущенные компоненты устанавливают на компьютеры-серверы, где они должны впредь работать. Более сложные системы также нуждаются в инсталлировании прочего поддерживающего программного обеспечения (например, новая версия процессора баз данных, и т.д.). Часто большую систему устанавливают в нескольких средах — например, в дополнение к тестовому серверу, который может быть впоследствии использован для обучения пользователей и для других целей.
- Адаптацияи обновление — в процессе обновления устанавливают новую версию системы, адаптации — это также изменение системы, но ее основанием является, главным образом, изменение в клиентской среде.
- перенос данных из старой системы — в используемой ранее системе имеются, как правило, данные, которые следует использовать и в дальнейшем. Желательно создание инструмента автоматического переноса данных, который запускают однократно при переносе данных из старой системы к новую. Механизм переноса может быть довольно сложным, особенно если структуры данных старой системы и новой системы существенно различаются. Если совокупность данных — небольшая и / или выработка алгоритма автоматического преобразования чрезмерно сложна, можно данные переносить вручную. В этом случае может понадобиться создать рапорты для извлечения данных из старой системы и формы (средства) для ввода данных вручную во внедряемую систему;
- внесение измененийв другие приложения, которые должны работать совместно и / или которых используют вместе развертываемым с программным продуктом;
- подготовкаи проведение обучения людей, соприкасающихся с программным продуктом, согласно следующим ролям:
- обычные пользователи
- администраторы
- поставщики услуг сопровождения
Обучение должно охватывать как теоретическую, так и практическую части. Практическую часть желательно проводить в созданной среде (как программное обеспечение, так и данные), созданной для тестирования и / или обучения, прежде всего для предотвращения рисков в интересах конфиденциальности, доступности и целостности реальных данных;
- созданиесостояния готовности при управлении кризисной ситуацией и для поведения в кризисных ситуациях. Возможные кризисы при внедрении программного продукта:
- отказ программы в рабочей среде
- обнаружение в программе ошибок
- потери данных.
Ошибка в программном продукте может привести к приостановке бизнес-процессов, значительный экономический ущерб и ущерб репутации предприятия или учреждения государственного сектора. В ходе подготовки к кризисной ситуации согласовываются роли, процессы и управление: как поступать в кризисной ситуации, как общаться с пользователями и теми, кто занимается регулированием кризисной ситуации, как и когда, информировать общественность, как при необходимости и возможности использовать старое программное обеспечение и прочее.
Люди также являются риском при внедрении программного обеспечения. Особо это может проявиться при внедрении программного обеспечения впервые, когда может произойти сильное противостояние внедрению. Часть из этих рисков можно преодолеть при помощи вышеупомянутого обучения. Вдобавок, необходимо продумать ежедневные процедуры. Могут ли используемые до сих пор процедуры функционировать теперь таким же образом, если будет использоваться программная система? Часто нет. Это может обусловить большую человеческую путаницу и добавить противостояние к обновлениям. Таким образом, в дополнение к техническому обучению, как использовать программное обеспечение, следует обучать работников обдуманно, научить их думать по-новому.
Например, как после введения цифровой (дигитальной) системы управления документами поступить со счетом, чтобы его смог бы перечислить бухгалтер? Или как может ученик после внедрения новой учебной информационной системы узнать о переэкзаменовках, если больше такую информацию не вывешивают на стене? Говоря в общем, при внедрении программного обеспечения может понадобиться перепланирование необходимых бизнес-процессов, у которого есть две стороны — согласование бизнес-процессов, которое представляет организационную точку зрения, приемка и одобрение, которое представляет точку зрения индивидуума.
Кейперс Джонс (Capers Jones) делится следующими рекомендациями (best practices) в своей книге « Software Engineering Best Practices», которыми можно воспользоваться во время этапа внедрения:
- Объединяйтесь с сетью пользователей того же самого приложения (если эта сеть существует)
- Просите совета и рекомендации по внедрению программного обеспечения у нынешних пользователей программного обеспечения
- Находите консультантов, у которых есть опыт по внедрению.
- Побеспокойтесь о создании подходящих специализированных курсов и находите соответствующие курсы.
- Приспосабливайте программное обеспечение для местных нужд.
- Создавайте интерфейс между новым разработанным программным обеспечением и заменяемым программным обеспечением.
- Регистрируйте и сообщайте об ошибках и дефектах, которые возникают во время внедрения.
- Устанавливайте патчи и обновления производителя программного обеспечения.
- Оценивайте успешность нового приложения.
Согласно этому же автору этап внедрения может быть очень длинным, даже 12 месяцев, и потребовать работу нескольких десятков людей и около 1 миллиона долларов наличными.
Программное обеспечение, которое не создается непосредственно для данной фирмы, может потребовать также довольно долгой и тщательной настройки прежде, чем его вообще можно будет использовать.
Ранее описанное внедрение программного продукта скорее является однократным действием. В соответствии с моделью жизненного цикла программного обеспечения затем следует фаза сопровождения (поддержки), которая по существу продолжается до тех, пока программное обеспечение остается в эксплуатации.
В связи с изменениями в бизнес-среде, законодательстве, ведении бизнеса необходимо приводить программное обеспечение в соответствие со временем (обновлять), также требуется, чтобы выявленные ошибки программного продукта были бы исправлены. Это помогает осуществлять управление изменениями программного продукта в согласованном порядке, в этом также помогают специальные CASE-средства, которые позволяют сообщать об ошибках в продуктах или о необходимости исправлений; задавать приоритеты требованиям об изменениях на основе важности, критичности и пр., направлять на выполнение исправлений, управлять версиями программного обеспечения и т.д.
Кроме того, вышеописанные этапы внедрения присутствуют, по крайней мере, частично, при проведении значительных изменений в программном обеспечении (например, добавляя новую функциональность)