 Часто можно услышать вопрос: чем занимается проектный отдел? Ответ «выпускает проекты» слишком расплывчатый и потому не устраивает. Хотелось бы конкретики. Так чем именно занимаются люди, которые ежедневно приходят в офис и сидят перед мониторами по 8 часов?
Сначала определимся с этапами работы проектировщика, которые во всех организациях примерно одинаковые и выглядят следующим образом:
1. Получение технического задания.
2. Сбор исходных данных.
3. Разработка технического решения.
4. Передача и получение задания смежным отделам.
5. Выполнение чертежей.
6. Вывод документации на печать и ее подготовка к передаче заказчику.
На мой взгляд, ключевыми моментами, от которых напрямую зависит эффективность проектирования, являются:
– разработка технического решения, оптимального для данного объекта, и выбор оборудования, которое будет удовлетворять по техническим характеристикам, соотношению цена/качество и иметь приемлемые сроки поставок;
– выполнение читаемых чертежей не только для внутрикорпоративного пользования, но и для работы субподрядчиков;
– ориентирование на происходящее на объекте и рынке.
Вроде бы понятные и элементарные вещи, но, как ни странно, на практике в расчет они часто не принимаются и упор делается совсем на другом.
Чтобы понять, на каких этапах возможны задержки, проследим за всей цепочкой проектирования.
1. Получение технического задания. Здесь возможны варианты:
– лично в руки в распечатанном виде;
– по электронной почте;
– по программе документооборота.
Последний вариант не гарантирует своевременного получения технического задания. Хотя многое зависит от того, насколько хорошо отлажена работа с данной программой в организации. Чаще всего в программе документооборота приходится долго копаться, чтобы найти нужный документ, а оповещение о его поступлении тонет среди массы других оповещений.
2. Сбор исходных данных:
– ждать, когда заказчик их предоставит;
– обратиться к заказчику, выехать на объект;
– воспользоваться предварительными, на основании которых был заключен договор.
3. Разработка технического решения:
– тщательно изучить объект, предложения на рынке и выработать оптимальное решение;
– принять за основу пилотный проект (или эскиз проекта, на основании которого была рассчитана ориентировочная стоимость оборудования при заключении договора).
С одной стороны, раз договор заключен и заказчика устроил эскиз, то менять ничего не нужно. Но эскиз есть эскиз, он создается на скорую руку, без учета особенностей объекта, хотя бы потому, что при поверхностном взгляде они не видны.
Выработка оптимального решения потребует дополнительных ресурсов со стороны компании-подрядчика, но позволит получить более эффективную систему и, скорее всего, сэкономит время на монтаж и дальнейшее проектирование (в случае если в пилотном проекте обнаружатся недочеты и его придется переделывать, а такое при использовании непродуманного решении бывает очень часто). Тут следует оговориться. Непродуманное решение не означает неправильное в принципе. Это шаблон, не учитывающий особенности конкретного объекта. То есть по большому счету шаблон подходит, но в деталях возможны расхождения.
4. Передача и получение задания смежным отделам:
– лично в руки в распечатанном виде;
– по электронной почте;
– по программе документооборота.
Я знаю организацию, в которой применяется последний вариант, причем в усложненной форме. Алгоритм работы такой:
– найти шаблон (хорошо спрятанный) в программе документооборота;
– заполнить его;
– распечатать, собрать подписи четырех (!) сотрудников: начальников обоих отделов, ГИПа, нормоконтролера;
– зарегистрировать полученный документ в архиве;
– отсканировать и вставить в программу документооборота;
– с помощью программы документооборота послать на согласование начальникам отделов. |
 Когда начальники отделов поставят галочки в нужные графы программы, задание поступит исполнителю. И не факт, что исполнитель сразу заметит это задание, потому как программа документооборота выдает оповещение о создании в ней любых документов, в том числе и созданных тем же исполнителем. Это примерно, как если бы по электронной почте приходили сообщения себе от себя же.
Сбор подписей может очень надолго затянуть процесс. Сотрудника нужно застать на месте, чтобы он был не занят и чтобы документ его устроил. Нет, не по содержанию, ибо вникать в расчеты никому неинтересно. Чаще всего предъявляются претензии к оформлению. Вот только с какой целью? Это внутрикорпоративный документ, который не попадает ни к заказчику, ни на экспертизу. Разве что только для того, чтобы затормозить работу.
5. Выполнение чертежей.
Несомненно, нужно придерживаться ГОСТа. Но ГОСТ допускает варианты в оформлении и обозначениях. Я всегда считала и считаю, что проект выполняется не только для его сдачи на экспертизу, но и для того, чтобы по нему выполнить монтаж. Чтобы по чертежам успешно смонтировать оборудование, нужно, чтобы они были актуальными, информативными и читаемыми.
Кроме ГОСТов есть еще и внутрикорпоративные стандарты, которые ГОСТам, конечно же, не противоречат. Эти стандарты создаются с благими намерениями. Порой над ними трудятся целые отделы, постоянно усовершенствуя и вводя новшества. В результате имеем талмуды инструкций, которым нужно следовать. Например, использование кодировок KKS.
KKS представляет собой систематизированный набор кодов, построенный по принципу «от общих групп к частным подгруппам». Кодирование KKS само по себе полезно и его применение обосновано для АСУТП, но стоит ли использовать его для системы безопасности?
Обозначения KKS очень усложняют разработку и чтение проекта. Вот пример из проекта:
00UYA10 R002 – это обозначение помещения. В привычном виде эта запись будет выглядеть так: коридор пом. 14.
Код содержит в себе отметку высоты, назначение здания и самого помещения.
Информация, несомненно, полезная, но из-за большого количества символов воспринимается с трудом.
Или пример обозначение кабеля: 30СYЕ23005. Оборудование кодируется очень похоже на то, как кодируется кабель, и запись может отличаться лишь одной буквой. Например, вместо ИБП8 можно увидеть 0СYТ23005.
В первом случае сразу ясно, что это источник бесперебойного питания и, скорее всего, кроме этого ИБП в проекте есть еще как минимум 7 других, а глядя на 30СYТ23005, не разберешь, что это: номер кабеля, номер помещения или кнопка выхода. При таких обозначениях зрительная память не работает, и приходится по нескольку раз перепроверять проект.
Замечательно, что в обозначениях зашифрована масса информации. Только кто ее расшифровывать будет? Монтажник, которому в руки попадет проект? Он быстрее сообразит, что к чему, благодаря опыту, а не кодировкам. Но с толку эти кодировки собьют не раз. И не только монтажника, но и всех, кто имеет отношение к проекту, в первую очередь самого проектировщика.
При чтении инструкции все понятно, ККS – чудо, а не система, но, когда инструкцию закрываешь, видишь в проекте лишь набор символов. Не воспринимаются эти хитроумные обозначения. Даже если знать систему кодирования как родную, все равно приходится напрягать память, чтобы определить, на каких чертежах, какое оборудование и кабели отображены.
На мой взгляд, чем обозначения проще и короче, тем они лучше для восприятия и запоминания. К слову, ГОСТ не возбраняет использование в обозначениях кириллицы, поэтому для российских проектов (а большинство проектов применяется внутри страны) мне больше нравятся применять буквы русского алфавита.
6. Вывод документации на печать и ее подготовка к передаче заказчику:
– выпустить 1 экземпляр для проверки, затем, когда требуется по договору, передать экземпляры заказчику;
– выпустить все экземпляры, придерживаясь внутрикорпоративного графика.
Первый вариант как минимум экономит бумагу.
Второй вариант дисциплинирует, но, если проект включает в себя несколько взаимосвязанных систем и объектов, выпускать документацию раньше времени нерационально, поскольку непременно придется вносить изменения. Изменения в сложных проектах часто бывают связаны со стыковками между объектами и системами или с обновлением исходных данных.
В одной организации мне встретился уникальный алгоритм выпуска проектной документации (интересно, применяется ли он где-либо еще?):
1. Распечатать и подписать 1 экземпляр.
2. Зарегистрировать в архиве каждый лист проекта (внести номер от руки на боковом штампе).
3. В программе документооборота согласовать чертежи с руководством.
4. Зарегистрированный экземпляр отсканировать и размножить.
5. Передать заказчику.
Документация передана, казалось бы, работа закончена. Ан, нет, разработчики алгоритма упустили из виду две аксиомы проектирования: «нет предела совершенству» и «все течет, все меняется».
Для того чтобы внести изменение, нужно проделать следующее.
1. Из программы документооборота выудить шаблон разрешения на внесение изменений.
2. Заполнить шаблон, указать причины изменений. Как правило, в качестве причины указывается требование заказчика.
3. Распечатать, собрать подписи 5 сотрудников – на этот раз подпись еще и главного инженера.
4. Зарегистрировать полученный документ в архиве.
5. Внести изменения в чертежи.
6. Распечатать, подписать, зарегистрировать в архиве, согласовать в программе документооборота.
7. Измененные чертежи передать заказчику.
При таком алгоритме работы одним изменением проекта дело не ограничивается, и каждый раз процедура повторяется.
Что любопытно: если вопрос не терпит отлагательства и корректировать проект нужно срочно, на реверансы с оформлением закрываются глаза, и чертежи выпускаются без лишних сложностей вроде регистрации в архиве и получения разрешения, что указывает на их ненужность – цейтнот расставляет все по местам.
Корпоративные стандарты нужны, но они должны быть разумными, направленными на ускорение работы, а не усложнять ее.
Можно идти по простому пути, посвящая время важным этапам: разработке технического решения, обследованию объекта, выбору оборудования. Или же погрязнуть в деталях, которые на эксплуатационные свойства создаваемой системы не влияют, зато поглощают уйму времени.
|
