Проект автоматизации – Проекты по автоматизации процессов производства, проекты АСУТП

Примеры выполненных проектов автоматизации – Телеавтоматика

Задача

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

Сбор сведений

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

Формируем список ключевых аспектов работы системы:

1. Взвешивание автомобилей производится в автоматическом режиме.
2. Сотрудники заказчика не участвуют в процедуре взвешивания.
3. Процесс взвешивания автоматически документируется. Сохраняются фото- и видеоматериалы, подробный журнал прохождения автомобиля по весам.
4. Программа подготавливает печатные формы документов для рейса.

Мнемосхема системы управления весовой:

Заказчик одобряет. Приступаем к реализации.

Читать далее Автоматизация весов на терминале перегрузки угля →

Проект интересен тем, что глубина нашего участия в нём выше чем в предыдущих проектах. Собственник решил не покупать готовый завод, а построить свой практически с нуля из комплектующих; спроектировать его с учетом тех потребностей, которые не могут быть реализованы при помощи серийно выпускаемых заводов.

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

Общая мнемосхема завода:
Читать далее Автоматизация бетонного завода / г. Артём →

Это был один из наших первых проектов по автоматизации бетонно-смесительного узла. Завод достался нам в плачевном состоянии. Старый, немецкий, 60-х годов выпуска бетонно-растворный узел скипового типа. Первостепенной задачей была не столько автоматизация, сколько замена старого ручного пульта на новый. Пульт управления был в плохом состоянии, периодически отказывался работать, грелся, гудел и пару раз пытался воспламениться.

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

Читать далее Автоматизация БСУ / БРУ / Артём →

Задача:

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

Процесс выполнения практически любого объекта начинается со сбора детальных сведений о решаемой задаче: какие грузопотоки сейчас имеются, как происходит процесс учета, с какими проблемами сталкивается заказчик и как их решает. После сбора информации – перерабатываем ее, формируем детальное техническое задание. Затем согласовываем и приступаем к проектным работам.

Читать далее Автоматизация карьерных весов →

Задача:

Автоматизировать обслуживание автотранспорта, ввозящего и вывозящего ТБО с территории мусороперегрузочной станции.

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

1. Автоматизировать взвешивание ТБО, поступающих на территорию мусороперегрузочной станции. Пропуск автотранспорта осуществлять по бесконтактным карточкам в автоматическом режиме без участия оператора.
2. Вести учёт поступающих ТБО в разрезе автомобилей и контрагентов.
3. Автоматизировать взаиморасчёты в безналичной форме.
4. Производить обмен накопленной информацией с 1С через web-сервис.

Читать далее Автоматизация весовой по карточкам на полигоне ТБО →

диспетчеризация и автоматизация котельной

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

Проектирование, комплектация, изготовление и монтаж:

• Силовых шкафов
• Шкафов автоматики для сбора и передачи информации с объектов (интеграция в существующие SCADA системы)
• Систем SCADA и HMI для нужд тепловой автоматики
• Обслуживание систем автоматики котельных
• Цифровых и аналоговых сетей видеорегистрации
• Технологических сетей связи для нужд автоматики и телемеханики

Читать далее Автоматизация котельных →

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

Одна из установок отгружает бетон во внутренние цеха для производства железо-бетонных изделий, а также может производить товарный бетон и выгружать его в бетоновозы (миксеры). Вторая установка используется только для производства товарного бетона.

В данном случае нами были произведены следующие работы:

1. Проектирование и изготовление шкафов релейного управления (без силовой части)
2. По максимуму задействовано старое работающее оборудование, что позволило снизить стоимость автоматизации
3. Пульты ручного управления заменены на новые
4. Разработано и поставлено программное обеспечение и оборудование для управления заводом
5. Смонтированы шкафы управления, кабельные линии и небольшое количество недостающих для работы датчиков
6. Поставлена система резервного питания для управляющей электроники

Читать далее Автоматизация бетонных заводов и БСУ →

teleavtomatika.com

Best practice проектов автоматизации бизнес-процессов от профессионала. Часть 1

Андрей Кочетков – Руководитель консалтинговых проектов «Консист Бизнес Групп»*

Любой проект в консалтинговой практике, связанный с разработкой технического задания, функциональных требований или оптимизацией бизнес-процессов – задача трудоемкая, но необходимая для того, чтобы обеспечить базу комплексного проекта, свести в единую картину ожидания заказчика и прогнозируемые результаты. Руководитель консалтинговых проектов «Консист Бизнес Групп» Андрей Кочетков расскажет о том, на что следует обращать внимание, какие трудности могут возникать в проектах и как их преодолевать, поделится особенностями ведения проекта в компании diHouse – крупном оптовом дистрибуторе.

— Андрей, расскажите, пожалуйста, в целом о Ваших проектном опыте, Все ли Ваши проекты включают этап описания бизнес-процессов?

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

— Давайте обозначим несколько наиболее универсальных этапов, которые присутствуют в большинстве проектов. Кратко опишите их, пожалуйста.

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

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

Если в проекте необходимо глубокое обследование, мы проводим интервью не только с основными ключевыми сотрудниками, но и с теми, кто прямым или косвенным образом влияет на выполнение процесса.

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

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

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

— Часто ли так случается, что существующие бизнес-процессы меняются при внедрении информационных систем?

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

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

— Что самое главное, что нужно учесть в работе по оптимизации бизнес-процессов?

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

— Этой модели достаточно для начала проекта автоматизации?

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

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

— Если сравнивать проекты разных заказчиков, отличаются ли клиенты друг от друга в зависимости от того, например, это государственная компания или коммерческая структура?

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

— Какие ошибки наиболее часто допускаются, на Ваш взгляд, на каждом из этапов? И что Вы предлагаете, чтобы их избежать?

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

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

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

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

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

При разработке рекомендаций по модернизации корпоративных информационных систем и план-графика модернизации корпоративной информационной системы (КИС) организации важно уделить особое внимание ИТ-подразделению Заказчика. У ИТ-подразделения могут быть технические ограничения (архитектурные ограничения, техническая политика). Также необходимо учесть при разработке концепции автоматизации наработанный собственный опыт внедрений ИТ-подразделения.

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

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

Продолжение темы — во второй части статьи. Здесь Вы найдете:

— Кейс проекта внедрения ИС в компании diHouse;
— Работа с заказчиком: «одинаково смотрим на вещи»;
— Опыт применения эффективного инструментария для подготовки ТЗ на автоматизацию.

Продолжение выйдет в ближайшее время на страницах нашего корпоративного блога.

*Справка о компании:

«Консист Бизнес Групп» объединяет ведущие консалтинговые активы ГК «ЛАНИТ» и «Группа Систематика». Бизнес группа строится на базе компаний «ЛАНИТ Консалтинг», TOPS Consulting, Sciener и LC Europe и объединяет в многопрофильный ИТ-холдинг практики управленческого консалтинга, разработки, внедрения и сервисного обслуживания ИТ-решений для работы с заказчиками из ключевых отраслей российской экономики.

habr.com

Автоматизация управления проектами в российском бизнесе

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

Автоматизация проектов: управление без рисков или модный тренд?

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

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

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

Любому руководителю хочется ускорить работы по проекту. Благодаря функционалу программы управления проектами можно увеличить скорость хода проекта до 70 %, в зависимости от специфики. Наиболее заметны результаты автоматизации управления в компаниях с долгосрочными и дорогостоящими проектами: строительство, информационные технологии, нефтедобыча, сложные сборочные производства.

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

Решение: доверить управление проектом программе

Какие конкретно задачи способна взять на себя информационная система?

• Планирование — важная часть управления проектом. Рассматриваются риски, планируются работы с учетом ресурсов и ограничений, указываются контрольные точки, ведется финансово-экономический расчет. План можно быстро переделать с учетом новых показателей — по сути, сделать анализ «что — если».
• Хранение документов и документооборот. Важно выбрать программу, которая не усложняет, а облегчает управление проектом.
• Коммуникация и обмен данными. Задача автоматизации — создать единое информационное пространство. Качество проектного управления связано с возможностями оперативного обмена данными внутри компании, а также между компанией, клиентами и поставщиками.
• Контроль. Автоматизация управления проектами позволяет руководителю контролировать сотрудников, менеджерам в несколько кликов получать информацию о процессах, директору — знать, на каком этапе находятся проекты.
• Быстрое принятие управленческих решений. Оперативный доступ к информации и владение объективной картиной в любой момент времени увеличивают скорость принятия решений.

Если обобщить, результаты внедрения автоматизированной системы управления проектами включают следующие пункты:

• увеличение скорости реализации проекта;
• рост эффективности управления проектом;
• оптимизация использования ресурсов компании;
• улучшение коммуникации в проектной команде;
• рост эффективности управления сотрудниками и их загрузкой.

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

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

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

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

Система управления проектами — наша для наших

Популярные в России программы управления проектами — Artemis, Open Plan, Microsoft Project, Spider, семейство программ «1С», в том числе «1С:Управление проектным офисом» и «1С:Документооборот», Sure Track, Time Line, ABT Workbench.

Специфика российского бизнеса и законодательства в этой сфере такова, что для наших компаний больше подходят флагманские отечественные системы. Одни из ведущих систем автоматизации управления проектами — линейка «1С». Эти продукты более 30 лет успешно используются на рынке, позволяют работать в режиме online и on-premis.

В качестве примера, как конкретно программа автоматизации помогает управлять проектом, рассмотрим работу с системой «1С:Документооборот». В контексте управления проектом эта программа может помогать со всеми комплексными процессами. А именно:

• Планирование. Вы можете загрузить готовый план из Excel или MS Project или создать план в системе, воспользовавшись встроенными инструментами автоматизации.

«1С:Документооборот» умеет рассчитывать сроки и условия с учетом предшествующих процессов. Например, у задачи «найм перевозчиков» есть две задачи-предшественника: «заказ кресел» и «заказ столов». Между ними и «наймом перевозчика» указан тип зависимости: «окончание-начало»: следующая задача начнется после окончания предыдущей. Система будет указывать срок задачи «найм перевозчиков» с учетом срока выполнения этих двух заказов — кресел и столов. А если вы поставите тип зависимости «начало-начало», в плане отобразится одновременное начало задач.

• Визуализация плана. Благодаря разным режимам просмотра вы можете адаптировать план под ситуацию. Например, в режиме просмотра «Планирование» вы сможете изучить плановые трудозатраты. А в режиме «Анализ трудозатрат» — соотнести этот план с фактом. Один из режимов — известная диаграмма Ганта с возможностью передвижения задач.

• Вести учет всех данных в разрезе проектов (документы, файлы, процессы, задачи, почта, мероприятия и прочее).
• Вести учет трудозатрат. Вы видите, кто исполнитель по задаче, сколько часов должно уйти на выполнение задачи по плану, сколько ушло по факту. Можно посмотреть, сколько всего у исполнителя задач в работе, сколько выполнено, какие задачи не начаты вовремя, какие скоро должны завершиться или начаться.
• Настраивать права доступа к проекту.

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

• Пользоваться встроенной почтой. На основании писем можно создавать процессы, проекты, мероприятия, входящие, исходящие и внутренние документы, вести учет времени.
• Общаться в форуме. В интерфейсе программы сотрудники могут обсуждать рабочие документы, отвечать на вопросы и задавать их.
• Вести календарь. Общий, личный, с ограниченным доступом, с уведомлениями и без.
• Контролировать! В системе «1С:Документооборот» вы сможете поставить на контроль практически все, что угодно.
• Согласовывать прямо в программе. Вы можете посмотреть среднюю продолжительность согласований у разных сотрудников, отследить, на что вообще уходит время сотрудников, кто задерживает исполнение документов, какие документы зависли.

Что еще выгодно отличает систему «1С:Документооборот» от прочих инструментов автоматизации управления проектами — так это возможности интеграции. Программа может быть интегрирована со всей линейкой продуктов «1С», в наличии множество механизмов интеграции:

1. Web-сервисы;
2. RESTful API;
3. HTTP;
4. COM;
5. ODBC;
6. XML;
7. Email;
8. FTP;
9. и правила обмена.

Еще одно преимущество перед другими инструментами автоматизации проектного управления — all inclusive. В «1С:Документооборот» встроено большое количество сервисов: ЭЦП шифрование, штрихкодирование, потоковое сканирование, рабочий стол руководителя, работа через интернет, распознавание сканов и штрих-кодов, учет бумажного документооборота, МЭДО/ЭДО, и это не полный перечень.

Но вы, конечно, хотите знать, каких конкретных — то есть выраженных цифрами — результатов можно достичь, используя «1С:Документооборот», как систему автоматизации в проектном управлении. Чтобы ответить, мы провели опрос среди наших клиентов. Вот результаты:

Повышение скорости работы по комплексным процессам — отметили 80 % компаний.

Улучшение исполнительской дисциплины — указали 53 % компаний.

Существенно снизился риск утери документов у 50 % компании.

Наведение порядка в процессах отметило 47 % компаний.

Соблюдение графиков платежей и исполнения договорных обязательств выросло в 18 % компаний.

12 % руководителей сказали, что получили возможность проанализировать и оптимизировать деятельность компании в целом.

Хотите узнать, какие возможности несет система «1С:Документооборот» конкретно для вашей компании?

Обратитесь сегодня и получите индивидуальное предложение?
Заполните форму — наш эксперт свяжется с вами и проконсультирует бесплатно.

Заказать консультацию

Автоматизация управления проектами: рецепт идеального СУПа

«1С:Документооборот» — инструмент, хорошо работающий в России и показывающий прекрасные результаты. Но все специфично. Маленькой компании с однотипными проектами может подойти «1С:Битрикс». Да, сейчас эта система не умеет настраивать взаимозависимость задач и имеет ряд других ограничений, но иногда большой функционал и не нужен, к тому же Битрикс продолжает развиваться. А крупный бизнес со сложными проектами нуждается в инструменте автоматизации управления с широкими возможностями. Такие предприятия часто выбирают MS Project или даже комплексные системы класса ERP на платформе «1С». В «1С:Документооборот» функционал чуть уже, чем в MS Project или 1С:ERP, но работа с «1С:Документооборот» существенно проще, а значит, быстрее можно обучить персонал.

Часто сравнение различных АСУП переходит в баталию — по форме идеологическую, по существу вкусовую или торговую. Но спор этот почти всегда беспредметен. Лучше всего та система, которая соответствует потребностям компании.

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

Есть ли жизнь после проекта?

Есть, и очень бурная. После внедрения АСУП вам предстоит позаботиться об обучении персонала и о технической поддержке системы. Подумайте, как вы будете это делать: своими силами, с привлечением компаний или консультантов, или, может, удобнее будет работать с одной компанией-интегратором, которая окажет весь комплекс услуг?

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

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

Хотите узнать, что мы можем вам посоветовать? Напишите нам прямо сейчас!

rarus.ru

Проект по автоматизации производства: шансы на успех

Реймонд Тистер, Дейв Адлер

 

Три основных критерия, позволяющих определить успех проекта:  содержание, график, бюджет

 

За последние пять лет у нас была возможность ознакомиться с результатами более чем 100 завершенных проектов по автоматизации. Количественная оценка, проведенная соавтором статьи Дейвом Адлером (Dave Adler) включила множество параметров, от детального анализа расходов до мнения руководства компаний о результатах проекта по промышленной автоматизации. Анализ показал, что три главных критерия оценки проекта – содержание, график и бюджет. И у менее чем 20% проектов показатели в этих областях достигли поставленных целей. Это означает, что – согласно объективным данным – когда компания начинает проект промышленной автоматизации, с вероятностью 80% поставленные цели НЕ будут достигнуты, или будут достигнуты позже запланированного времени, или бюджет будет превышен. Ошеломляет, не так ли?

 

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

 

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

 

Содержание проекта

 

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

 

 

Рис.1. Содержание проекта определяется многими функциональными областями.

 

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

 

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

 

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

 

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

 

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

 

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

 

Эффективный график

 

Содержание проекта – это ответ на вопрос «что нужно сделать». График проекта отвечает на вопрос «когда и как это будет сделано». Он описывает план по его внедрению, а также указывает, на каком именно этапе проект сейчас находится. Хорошо разработанный график – логичное представление плана проекта, и доказательство того, что цель достижима. Также, это лучший инструмент для любого менеджера проекта, желающего оценить влияние предлагаемых изменений на проект.

 

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

 

Рис. 2. Разработка графика проекта требует детального понимания того,

как будет реализован проект

 

Разработка графика проекта позволяет выявить зависимости от внешних и внутренних факторов, а также идентифицировать потенциальные риски проекта. Особенностью проектов автоматизации, которая делает их столь сложными, является то, что производственные процессы сильно отличаются друг от друга, в зависимости от типа производства (непрерывное или дискретное и т.д.), уровня автоматизации, системы управления (ПЛК или РСУ). Создание графика включает в себя определение этих рабочих процессов и позволяет специалистам в области автоматизации согласовать план с ключевыми участниками проекта. 

 

ЧАСТЬ II

Структура декомпозиции работ

 

При создании графика проекта очень важна его организация. Организация работ в рамках проекта называется «структура декомпозиции работ» (англ.: work breakdown structure или WBS). Чтобы разработать ее, необходимо учитывать, как специалисты по автоматизации будут проводить работы, а также, какой продукт или продукты будут получаться на выходе этих работ. В случае с проектами по автоматизации производства, структура может зависеть от последовательности строительства новых производственных площадей или, скажем, выведения оборудования из эксплуатации. Разработка эффективного графика предполагает визуализацию инсталляции аппаратного и программного обеспечения, а также организацию его таким образом, чтобы поддержать стратегию.

 

Рис. 3. Пример «структуры декомпозиции работ» для активностей по разработке ПО в рамках проекта по автоматизации

 

Определение необходимого уровня детализации графика может быть непростой задачей. Если выполнение задач длится слишком долго, график будет малополезным, а если очень недолго – команде по автоматизации придется постоянно отвлекаться на бесполезное уточнение мелочей. В руководстве Института по управлению проектами «PMBOK Guide and Standards» указано, что для всех работ, содержащихся в графике, должно соблюдаться следующее условие: «стоимость и длительность работ должны быть корректно оцененными и управляемыми». Использование идентифицируемых событий может помочь с определением деталей работ.

 

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

 

Поддержание графика проекта в актуальном состоянии важно для успешного управления проектом. Мы не раз видели, как проектные команды избегали пересмотра графика только потому, что не были готовы признаться себе в том, что установленные срок уже стали недостижимыми. Намного лучше реально смотреть на вещи, так чтобы сформулировать и включить в график корректирующие действия.

 

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

 

 

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

 

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

 

Прогноз стоимости проекта

 

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

 

Хотя бюджет и смета это разные вещи, смета – основа бюджета. База сметы должна быть понятной и достаточно детальной для поддержки действий по управлению проектом на протяжении всего его жизненного цикла. Компоненты сметы должны иметь количественное выражение, с прицелом на будущее управление изменениями. К примеру, при разработке ПО, идентифицируйте и выражайте количественно программные модули, так, чтобы будущие изменения были понятны. К примеру, программные модули ISA-88 идеально подходят для того, чтобы выражать содержание изменений в объеме требуемых для них усилий, когда речь идет о разработке ПО управления рецептурным производством. Даже если реальные количественные показатели неизвестны, когда готовится смета, предположения должны быть документированы, так, чтобы база сметы была ясной.

 

Для того чтобы на основе сметы разработать бюджет, необходимо провести анализ рисков и выразить в количественном измерении планы по их минимизации. Это позволит определить резервы бюджета. Не поддавайтесь искушению добавить определенную сумму «про запас» в сметную часть бюджета для покрытия рисков. Резервами, включенными в сметную часть, не так легко управлять, и они могут оказаться недоступными в нужный момент.

 

Управление бюджетом – это процесс постоянной проверки первоначальных предположений относительно сметы и возможных рисков. По мере продвижения проекта, используйте текущие показатели для проверки первоначальных оценок. Чем раньше будут определены те или иные тенденции или риски, тем раньше можно внести коррекции в планы и продемонстрировать, что проект находится под контролем. Постоянный мониторинг суммы окончательной сметы (англ.: estimate at completion или EAC) тоже может быть очень полезен в определении трендов.

 

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

 

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

 

 

Рис. 5. Бюджет проекта 

 

Управление проектами по автоматизации

 

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

 

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

 

Многие хорошие специалисты в области автоматизации начинают свою карьеру в области управления проектом очень похоже. Сотрудник успевает зарекомендовать себя в качестве хорошего специалиста в области КИПиА, и его назначают управлять большим проектом. И, внезапно, вчерашнему инженеру приходится заниматься координацией деятельности своих коллег, отвечать за содержание, график и бюджет проекта. Как эксперт в области технологий автоматизации, он всегда был сфокусирован на технологиях и приложениях. Однако если он не найдет достаточно времени для того, чтобы поближе ознакомиться с принципами ведения проектов по автоматизации, то в итоге, хотя и будет создана хорошая система автоматизации технологических процессов, сроки будут, скорее всего, сорваны, бюджет превышен – а эти явления руководству и ключевым участникам проекта, как правило, не нравятся. Разборки с руководством – то, что сложно забыть, и то, чего никто не хочет. Лучше учиться на ошибках других. Используйте эффективные практики управления проектами и продолжайте совершенствовать свои познания в области автоматизации. Перед тем, как принять на себя роль лидера, прочитайте как можно больше о предмете, посетите несколько тренингов и найдите хорошего наставника. По возможности.

 

Об авторах:

 

Реймонд Тистер (Raymond Teaster) ([email protected]) – совладелец Brillig Systems, компании по консалтингу в области проектов автоматизации. Более 25 лет опыта успешной реализации проектов для крупнейших компаний в химической, пищевой, полупроводниковой отраслях. Тистер – профессиональный инженер и руководитель проектов.

 

Дейв Адлер (Dave Adler) ([email protected]) – главный консультант в Brillig Systems. Более 35 лет опыта внедрения технологий автоматизации в фармацевтической отрасли. Консультант в области лучших практик по автоматизации, управлению проектами и развитию персонала. Профессиональный инженер и дипломированный специалист в области автоматизации. 

 

ua.automation.com

проект автоматизации инженерных систем в СПБ, Москве

Проект автоматизации Автоматизация инженерных систем в Санкт-Петербурге

 

, проектирование раздела Автоматизация системы отопления и вентиляции выполняется на основании следующих нормативных документов:

• Постановление правительства РФ от 16 февраля 2008 года N 87 — о составе разделов проектной документации и требованиях к их содержанию;
• Федеральный закон № 123 — Технический регламент о требованиях пожарной безопасности;
• ГОСТ 21.404-85 — СПДС. Автоматизация технологических процессов;
• СП 7.13130-2009 — Отопление, вентиляция и кондиционирование. Противопожарные требования.

Проект автоматизации. Автоматизация инженерных систем

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

Задачи, которые решает Проект автоматизация инженерных систем :

• местное, автоматическое и дистанционное управление вентиляторами приточно-вытяжных установок;
• местное, автоматическое и дистанционное управление вентиляторами дымоудаления и вентиляторами подпора воздуха;
• автоматическое и дистанционное управление противопожарными клапанами дымоудаления и подпора;
• автоматический запуск противодымной вентиляции по сигналу «Пожар»;
• дистанционный запуск с АРМ – автоматизированного рабочего места систем противодымной защиты и отключение установок приточно-вытяжной вентиляции;
• обеспечение подачи питания на вентустановки и контроль их работы с выводом данных на панель АРМ оператора;
• поддержание заданных параметров температуры и воздухообмена в помещении в зависимости от внешней температуры.

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

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

Схема 1 АОВСхема 2 АОВСхемы соединенийСхема соединений 2

Специалисты проектное бюро «AEC-PROJECT» выполнят проект автоматизации инженерных систем качественно и в установленный срок.

Заказать проект автоматизации системы отопления и вентиляции.

aec-project.ru

Best practice проектов автоматизации бизнес-процессов от профессионала. Часть 2

Андрей Кочетков – Руководитель консалтинговых проектов «Консист Бизнес Групп»*

Во второй части статьи руководитель консалтинговых проектов «Консист Бизнес Групп» Андрей Кочетков поделится успешными практиками, которые используются при внедрении информационных систем (ИС) на стадиях обследования бизнес-процессов, подготовки концепции автоматизации, разработки ТЗ. Материал содержит описание кейса по проекту внедрения ИС в компании diHouse – крупном оптовом дистрибуторе. Также рекомендуем ознакомиться с первой частью данной публикации, которая была размещена ранее на страницах нашего корпоративного блога.

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

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

— То есть Вы столкнулись с тем, что компании было необходимо внутреннее развитие, модернизация бизнес-архитектуры? Оцените трудности при обследовании бизнес-процессов в этой компании, встретили ли Вы сопротивление ключевых сотрудников?

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

— Процесс обследования получился более длительный, чем Вы ожидали?

— Да. Фаза обследования была незначительно увеличена. Это было необходимо. Мы собрали полную информацию о процессах, сильных и слабых сторонах, которые позволили нам принять на следующих этапах правильные решения.

— Андрей, находясь в процессе описания бизнес-процессов компании diHouse, как Вы можете оценить их качество выполнения на тот момент?

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

— Расскажите поподробнее, как в проекте diHouse сочеталось и проектирование, и описание бизнес-процессов?

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

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

— Андрей, скажите использовали ли Вы при проектировании процессов так называемые Best Practice?

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

— Проект diHouse включал все стандартные этапы работ, о которых Вы говорили?

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

— Как были организованы работы по проекту со стороны заказчика? Насколько руководители и сотрудники были задействованы в проекте?

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

Ключевые сотрудники проекта были задействованы во встречах по проектированию процессов и анализу предоставленных документов, отвечали на вопросы, предоставляли запрошенную информацию, принимали решения в спорных моментах, касающихся бизнес-процессов.

— Каковы дальнейшие направления развития этого проекта?

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

— Для описания бизнес-процессов diHouse Вы использовали Business Studio. Скажите, пожалуйста, какие плюсы дало использование программы?

— На текущий момент мы во всех наших проектах, не только diHouse, используем программный продукт Business Studio. Все результаты проекта в части описания бизнес-процессов фиксируются в формализованном виде и хранятся централизовано. Это полезно с точки зрения накопления и хранения знаний и экспертизы. Даже если у Заказчика нет жестких требований к нотации описания процессов, и даже если процессы мы не планируем согласовывать с заказчиком, они вносятся в BS.

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

В результате проекта в компании diHouse были развернуты два web портала Business Studio – модель бизнес процессов «до оптимизации» и модель оптимизированных бизнес-процессов. Таким образом сотрудники могут в любое время проанализировать, насколько их текущие выполняемые функции отличаются от эталонных оптимизированных вариантов, и скорректировать процессы в системе Business Studio самостоятельно.

— Какие еще преимущества от применения технологий бизнес-проектирования в своей работе можете выделить?

— В проектах внедрения ИС информация по процессам используется техническими специалистами, как первичный источник понимания бизнеса и особенностей Заказчика. На этапе подготовки к внедрению информационных систем первое, что технические специалисты, разработчики и консультанты по информационным системам видят и узнают о бизнесе Заказчика – это архитектура бизнеса компании, модель бизнес-процессов в Business Studio. Как показывает практика, ознакомление с бизнес-архитектурой заказчика перед внедрением ИС значительно ускоряет погружение сотрудников в проект и повышает качество конечного продукта.

— Какие результаты, как правило, Вы предоставляете заказчику, и помогает ли Вам Business Studio в формировании итогового результата?

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

Мы формируем в Business Studio все отчеты, которые предоставляем заказчику за исключением очень сложных документов, таких как: концепция автоматизации, технико-экономическое обоснование, план-график развития КИС. Для формирования сложных документов и других аналитических отчетов внутри проекта мы также можем использовать Business Studio для извлечения данных, собранных консультантами при обследовании.

— Какие перспективы по развитию методик у Вас имеются?

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

*Справка о компании:

«Консист Бизнес Групп» объединяет ведущие консалтинговые активы ГК «ЛАНИТ» и «Группа Систематика». Бизнес группа строится на базе компаний «ЛАНИТ Консалтинг», TOPS Consulting, Sciener и LC Europe и объединяет в многопрофильный ИТ-холдинг практики управленческого консалтинга, разработки, внедрения и сервисного обслуживания ИТ-решений для работы с заказчиками из ключевых отраслей российской экономики.

habr.com

автоматизация проектирования

Система автоматизированного проектирования в конструкторской подготовке производства

Системы автоматизированного проектирования (САПР) в настоящее время полностью себя оправдывают и являются во многих случаях единственно возможными методами при кон­струировании новых видов изделий (например, интегральных микросхем).

Под автоматизацией проектирования понимается автома­тизированный конструкторский синтез устройства с выпуском необходимой конструкторской документации (КД).

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

Важным результатом внедрения САПР являются и социо­логические факторы: повышение престижности и культуры труда при замене неавтоматизированных методов автомати­зированными; повышение квалификации исполнителей; со­кращение численности работников, занятых рутинными опе­рациями.

Наибольшую эффективность от внедрения <^mi и получить при автоматизации всего процесса проектирования — от постановки задачи, выбора предпочтительных вариантов построения изделия до технологической подготовки его про­изводства и выпуска.

До внедрения САПР на предприятии нужно прежде всего решить, применительно к каким задачам (или работам) про­ектирования наиболее эффективно ее применение, сформу­лировать требования к ней, определить в общем виде струк­туру, выделить этапы разработки системы и составить пере­чень необходимых для этого исследований, а также устано­вить, в каком объеме и виде она будет выдавать техническую документацию проекта и соответствие ее действующим нор­мативно-техническим документам (ГОСТ, ОСТ, СТП, РТМ и т. д.). Кроме того, должны быть выполнены работы по форма­лизации задач выбора и оптимизации проектных и конструк­торских решений, формированию библиотек типовых техни­ческих и проектных решений, информационных баз, пакетов прикладных программ и технологии автоматизированного про­ектирования.

САПР представляет собой организационно-техническую систему, состоящую из комплекса средств автоматизации про­ектирования, взаимосвязанного с проектировщиками и под­разделениями проектной организации. Проектировщик (кон­структор, технолог) входит в состав любой САПР и является ее пользователем, так как без человека автоматизированная си­стема не может функционировать. Объектом автоматизации в САПР являются действия проектировщиков, разрабатывающих изделия или технологические процессы. САПР нельзя создать вне конкретного производства, на котором она будет исполь­зована.

Комплекс средств автоматизации включает математиче­ское, лингвистическое, программное, информационное, методическое, организационное, аппаратное и техническое

обеспечение.

Математическое обеспечение составляют математические методы, модели и алгоритмы, необходимые для осуществле­ния автоматизированного проектирования.

Лингвистическое обеспечение — совокупность специаль­ных языковых средств проектирования, предназначенных для общения человека с техническими и программными компонен­тами САПР. Практика использования ЭВМ в проектировании привела к созданию наряду с универсальными алгоритмичес­кими языками программирования (АЛГОЛ, ФОРТРАН и др.) проблемно-ориентированных алгоритмических языков, специ­ализированных для проектных задач. Например, для автома­тизации вычерчивания изображений служат графические язы­ки ГП-ЕС, ГРАФОР, РЕДГРАФ, ФАП-КФ и др.

Программное обеспечение является непосредственным производным компонентом от математического обеспечения и представляет собой комплекс всех программ и эксплуата­ционной документации к ним.

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

Организационное обеспечение устанавливает взаимодей­ствие проектирующих и обслуживающих подразделений, от­ветственность специалистов за определение вида работ, при­оритеты пользования средствами САПР и другие регламенты организационного характера. Соответствующий комплект до­кументов составляют необходимые инструкции, приказы и штатные расписания.

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

Некоторые виды обеспечений объединены в группы, со­ответствующие наиболее простому представлению состава САПР, которому часто следуют на практике, когда не все обес­печения САПР разрабатываются, например, программно-ин­формационное обеспечение, которое воплощается в виде программ и сопровождающей документации. На этот вид обеспечения, как правило, приходится основная трудоем-

кость разработки. В общей трудоемкости разработки слож­ных САПР его доля достигает 75 % и более. Организационно-методическое обеспечение включает весь комплекс обеспе­чивающих мероприятий, а также регламентирующую и орга­низующую процесс автоматизированного проектирования документацию применительно к условиям конкретной проек­тной организации.

Решающими условиями возможности и целесообразнос­ти создания САПР являются: а) единство принципов построе­ния объектов проектирования; б) высокий уровень типизации и стандартизации элементов, из которых компонуют объекты проектирования; в) высокий уровень унификации процессов проектирования; г) большой объем проектных работ при ин­дивидуальных требованиях к объектам проектирования.

Эволюция средств и методов автоматизации проектиро­вания тесно связана с развитием вычислительной техники и программного обеспечения. На ранних стадиях создания САПР ЭВМ решала лишь отдельные инженерные задачи высокой трудоемкости. Затем с ее помощью стали выполняться в па­кетном режиме задачи технической подготовки производства, включающие: разработку плановых показателей; нормирова­ние расхода ресурсов; составление графиков запуска новых изделий, карт применяемости деталей, сборочных единиц, технологических карт; расчет режимов обработки деталей.

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

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

В общем случае процесс проектирования включает три эта­па: составление эскизного, технического и рабочего проектов.

Затраты труда на разработку объекта распределяются по эта пам приблизительно в таком соотношении: 10, 25 и 65 %

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

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

На стадии рабочего проектирования создаются рабочие чертежи и техническая документация. Деталировка, опреде­ление и нанесение размеров, составление спецификаций пол­ностью формализуются и могут выполняться на ЭВМ с исполь­зованием средств машинной графики.

При автоматизации проектирования наиболее важной явля­ется формализация как самого процесса, так и его объекта Она позволяет представить процесс проектирования в виде цепоч­ки (набора) последовательно (параллельно-последовательно) выполняемых процедур, при которых информация преобразу­ется, а исходные варианты приближаются к заданным проект­ным задачам. При этом если проекты могут быть сформу­лированы в виде информационных массивов для ЭВМ а опе­раторы проектирования (определенные процедуры, форму­лы, комплексы программ, стандарты, методики, модели и т. п.) представлены в виде пакета машинных программ то та­кой процесс называют автоматической разработкой (генера­цией) проекта. Если разработке на ЭВМ подлежат лишь неко­торые подкомплексы на отдельных стадиях, то такой процесс проектирования называется автоматизированным. В том слу­чае, когда оператор проектирования применим для ряда сис­тем или подкомплексов, выполняется типовое проектирование Нахождение (разработка) таких операторов является одной из важнейших задач построения любой системы проектирования Полный цикл процесса проектирования включает последо­вательное выполнение человеко-машинных процедур и их вза­имосвязи (рис. 17.2).

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

В соответствии с этапностью создания новой техники в комплексной (интегрированной) САПР выделяются следующие автоматизированные системы: управления процессами про­ектирования (АСУПП), проектирования (АСП), конструирова­ния (АСК), технологической подготовки производства (АСТПП), управления технологическими процессами изготовления опытных образцов (АСУТП), комплексных испытаний и обра­ботки изделий (АСКИО).

Каждая из функциональных составляющих базируется на едином комплексе средств автоматизации проектирования, включающих обеспечивающие системы типа автоматизиро­ванных банков данных (АБД), а также вычислительную систе­му, систему информационного обмена, графическую систему и систему разработки машинных программ.

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

Основу автоматизации стадии конструкторской подго­товки производства составляют две функциональные части комплексной САПР: автоматизированная система проекти­рования (АСП) и автоматизированная система конструиро­вания (АСК).

Автоматизированная система проектирования использует­ся как инструментальная подсистема САПР. Она создает про­граммы автоматизированного проектирования, и от ее эффек­тивности в значительной мере зависит эффективность дей­ствия комплексной САПР. Эта система выполняет несколько видов проектных процедур на стадиях разработки техничес­кого задания, технических предложений, эскизного и техни­ческого проектирования: анализ исходных данных, формирование технических характеристик, определение эффективно­сти изделия на стадии проработки изделия, когда перед про­ектировщиком стоит проблема выбора прототипа будущей новинки на основе упрощенной математической модели. Ре­зультатом функционирования АСП является структурная схе­ма изделия с данными расчета проектных параметров.

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

Для САПР любого уровня сложности основным структурным элементом является функциональная подсистема. Подсистемы обладают значительной функциональной автономностью и реа­лизуют определенный этап (фрагмент) процесса проектирова­ния. Однако САПР и их подсистемы взаимоувязаны с различны­ми компонентами интегрированных систем управления предпри­ятием или объединением (рис. 17.3).

studfile.net