«На данный момент самым популярным языком программирования является Java» таким заявлением можно начать очень крутой холивар.
Насчет «открытости», всегда считал, что «открытость» системы определяется наличием API и поддержкой различных протоколов обмена данными, например, SOAP, а не передачей исходного кода клиенту.
На сколько я знаю, «Лоцман» — коробочный продукт с преднастроенными бизнес-процессами. Изменить готовые процессы в нем не так то просто. Надо или иметь хорошие знания самого продукта, или платить денежки интеграторам. Причем денежки немалые (в одной из знакомых мне организаций на Лоцман потратили несколько миллионов, а «воз и ныне там»).
Мой жизненный опыт уже научил меня, что нет проектных организаций с одинаковыми бизнес-процессами. Каждой надо «шить на заказ». А в этом случае, нужен не коробочный продукт, а платформа с готовыми шаблонами процессов, которые изначально предполагают, что их не станут использовать «как есть», а скопируют и «допилят» под себя. Коей easla.com и является. Я свой процесс Задачи опубликовал для общего использования. Кто захочет, сможет его заимствовать и заточить под себя. Равно как и я когда-нибудь, когда пойду работать в другую организацию :)
Кстати, насчет непохожести. Есть ГОСТ 21.1101-2013, единый для всех проектных организаций. Регламентирует правила оформления проектной документации в организациях по всей России. Но даже в организациях находящихся в границах шести кварталов нашего города оформляют документацию по-разному, хотя вся она соответствует ГОСТ. Парадокс. :)
Немного ниже упоминали 1С, но когда я лично изучал возможности продуктов 1С, то заметил, что они не умеют хранить файлы. Это был большой минус. Не знаю как сейчас, возможно ситуация изменилась. Вы в курсе?
Насчет «best practice» (лучших практик). Как показывает мой жизненный опыт, с ними нужно быть поосторожнее. Изучать лучшие практики нужно и полезно (ITIL, PM BOK, CobiT), но тупой перенос их в работу, не оглядываясь на окружающую действительность, может только ухудшить ситуацию.
Конкретный пример из жизни. Недавно на хабре была статья о ревизиях. Ревизии — яркий пример «best practice». Они активно используются на «западе». Ревизии в целом — отличный способ контролировать процесс разработки проектной документации. В нашем ГОСТ нет такого понятия. Есть только изменения, которые позволяют контролировать только процесс изменения документации после сдачи в архив, но вот до этого момента, процедуры не регламентированы. В общем, ревизии — классная штука, если пользоваться ими правильно!
Но их начинают использовать сейчас все кому не лень и совершенно бездумно. Ревизии заменяют изменения в наше ГОСТ. Но наш ГОСТ никто не отменял. В итоге, и ревизии по стандартам «западных» и «прозападных» компаний, и изменения по ГОСТ приходится применять одновременно! Это вносит не просто путаницу, а порой полное непонимание, что и как идентифицировать и в какой момент. И не только на стороне исполнителя, но и на стороне заказчика. Таким образом, великолепный и признанный во всем мире «best practice» не только не помогает в работе, а напротив, тормозит ее, снижает эффективность и прозрачность.
По хорошему, надо было на уровне министерства или как они там сейчас называются, внести изменения в ГОСТ. Отменить изменения, вместо них описать работу с ревизиями и все! Было бы здорово!
Кроме этого существует понятие «зрелость процесса» и «зрелость компании». Многие «best practice» предполагают довольно высокую зрелость и того и другого, поэтому их запуск в «недозрелой» компании создаст больше вопросов, чем решений. Реализация же бизнес-процесса в точности по требованиям самой компании и быстрее и понятнее конечным пользователям от главного инженера, до техника.
Про SAP на хабре тоже недавно была «хвалебная» статья только подтверждающая опасения многих.
Кстати, не стоит забывать и про финансовую составляющую. Продукты 1С и уж тем более SAP имеют такой ценник, что в условиях современного кризиса их просто не потянуть, а easla.com почти бесплатная!
Адаптивная верстка все решает. Если руководство умеет пользоваться сотовым или планшетом, подключиться к интернет и зайти на сайт, то никаких проблем!
P.S. Таким же образом однажды воспользовался доступом к официальной переписке и отправил несколько официальных писем прямо со своей соты.
Ну если «высшее руководство их в этом активно поддерживало», то гиблое дело. Поддержка высшего руководства очень нужна при внесении любых изменений, тем более в управлении.
Оценить юзабилити можете в самой системе заимствуя процесс Задачи себе. Правда, учитывая его тесную интеграцию с другими процессами он может не завестись сразу и придется или поправить самому, или обращаться в техподдержку за помощь.
Мы уже успели попробовать альтернативный продукт. Боюсь указывать какой, «доброжелатели» заминусуют.
После неудачных попыток поискали другие. Системы, которые описывают свою бизнес-логику «кликами мышки» меня разочаровали. Верить в их возможности я перестал. К моменту, когда определились финансовая ситуация в организации стала такой, что покупать что-то было нереально.
Как указывал выше, важным критерием была гибкость системы, а easla.com позволяет описывать процессы кодом — куда уж гибче! Пусть нет блок-схем, но зато логика поведения точно такая, какая нужна.
Все задачи не относящиеся к проектным договорам проходят по так называемым «внутренним договорам». Нарочно созданы договоры «100» и «200» по которым выполняются внутренние задачи. Никаких проблем.
Спасибо за оценку моих трудов!
Вот только не Лоцман. Дурная весть за ним идет. Лично дело не имел, но коллеги с других организаций отзывают не очень лестно.
И, кстати, не стоит забывать про финансовую составляющую. Сколько будет стоить Лоцман ПГС или его аналоги, и во сколько обойдется easla.com.
Вопрос оптимизации и автоматизации все-таки в разных плоскостях. В статье описывается второе.
По поводу «жизнь… упростилась», вы правы. Инструмент был нужен в первую очередь главному инженеру, о чем я сказал в статье. Суть в том, что именно главный инженер наиболее организованный сотрудник компании и с мощной внутренней мотивацией. Его прямые подчиненные — ГИПы, по больше части уже не так заинтересованы в существовании автоматизированного механизма управления задачами. Им удобнее сослаться на плохую память, занятость, невозможность исполнения и прочее, чем выстроить под собой процесс исполнения поручений. Собственно с этим и начал бороться главный инженер сменив прежнего.
Объективным доказательством сказанного является тот факт, что до смены главного инженера ни один ГИП, ни разу не пришел и не попросил хоть какую-то систему управления задачами. Даже в sharepoint или outlook!
Сейчас, пусть не все задачи исполняются в срок, но они по крайней мере уже не забываются, не закрываются безосновательно и будут выполнены все равно хоть и со срывом сроков. Такого раньше не было. Поручения могли просто «похоронить» и «воскресали» они только когда звонил злой заказчик и требовал о нем вспомнить!
Насчет самодурства, сомневаюсь, т.к. знаю его лично. Количество задач 15-20 в день для коллектива в 200 человек с минимальным сроком выполнения 8 часов (а обычно 40 часов) — пшик! Не вижу препятствий выполнять все в срок!
Кстати, как указано в статье, вид «Авторский надзор» оказался крайне необходимым. Раньше подобный отчет ГИП собирал вручную и мог тратить на это неделю! Конечно, не 40 часов, но пока получит от каждого данные, пока сведет их вместе, пока сформирует смету… Таким образом запрошенная в понедельник смета могла попасть заказчику только в конце недели, а то и вовсе не попасть и из-за этого теряли деньги. Сейчас смета формируется на основании отчета в течении секунд 20 + время на фильтр к виду. На все про все минуты 2! Так что, считаю, что автоматизация управления задачами получилась не надуманной. И даже с реальной, а не потенциальной, экономической выгодой.
Я здесь немного ниже описал, что в описанной организации используется еще одна система — TDMS. Между TDMS и easla.com проведена условная черта ответственности. В TDMS вся проектная документация — весь ее жизненный цикл. В easla.com вся организационно-распорядительная документация и управления.
В том случае, когда первая система «упирается в потолок», ее поддержит вторая. И наоборот.
Об интеграции с Exchange пока речь не шла, а вот об отображении задач в виде диаграмм Гантта — да.
Скорее всего нужна не гремучая смесь, а платформа.
По опыту, например, для управления проектной документацией с момента создания и до момента сдачи в архив используется TDMS. На рынке полно «коробочных» продуктов, которые по стартовым возможностям превосходят TDMS. Однако, несколько лет назад мы все равно выбрали TDMS. Почему? Потому организации с абсолютно одинаковыми процессами встречаются нечасто. Правильнее сказать, организации с одинаковыми (типовыми) процессами бывают при условии, что работают в определенной нише, в которой процессы «устаканились» уже давным давно. Такие организации могут позволить себе «коробочные» или готовые облачные и онлайн сервисы с преднастроенными бизнес-процессами. Зарегистрировался. Добавил пользователей. Начал работать.
В нашем случае так не получается, т.к. бизнес-процессы компании не соответствуют никаким стандартам. Их надо «шить на заказ». Поэтому нужна не «смесь» нескольких продуктов, а платформа, на которой можно «замесить» несколько процессов разом.
Конечно, не исключаю вопросы интеграции. Но, как бы, по-крупному. Мы уже такой опыт поимели. TDMS скрещена с easla.com. TDMS скрещена с Outlook и Exchange. И easla.com умеет интегрироваться с LDAP.
Кроме этого, как уже написал выше, имеет значение гибкость системы. Возможность оперативно подстроиться под новые требования без остановки производства даже на 5 минут. Добавил атрибут. Описал логику и сразу в бой!
Я вам больше скажу! Они не только возмущаются, но и стонут, когда главный инженер «спускает собак» и заставляет навести порядок в задачах.
Недавно, примерно месяц назад, приезжал представитель одного заказчика и попросил провести ему экскурсию. Позадавал вопросы на местах. Дошел до ГИПа и попросил показать список задач по его проектам. А он у него весь красный! Не столько потому, что задачи не выполнены, сколько потому, что он их банально не закрыл вовремя, хотя все сделал! Крику было!
В общем, исполнительская дисциплина потихоньку перестает хромать. Эволюция…
Если смотреть с точки зрения только управления задачами, то наверное вы правы. Мне было важно интегрировать вроде как самостоятельный процесс управления задачами с кучкой других процессов, в частности, корреспонденцией и договорами. Все задачки привязаны к договорами и письмам. Кроме этого, как я описал в статье, интеграция очень тесная.
Например, при отправке исходящего письма происходит автоматическое комментирование задач, на основании которых оно (письмо) и появилось! Не знаю, на сколько такое возможно в Redmine.
Одна из целей — реализация всех бизнес-процессов на единой платформе.
В Jira есть возможность кроме задач управлять еще корреспонденцией (входящие и исходящие), договорами, заказчиками, инцидентами, изменениями, нормативной документацией, согласованиями? Навскидку.
Эээ… багтрекеры? В статье я же указал, что речь идет о проектной организации. Понимаю, что слово «проект» в современном обществе очень широкого понятия, поэтому уточню. Проектная организация — разработка проектов обустройства нефтегазовых месторождений. Сотрудниками организации являются инженеры, которые про багтрекеры слыхом не слыхивали. Попытаться затащить их в такую систему мне кажется уже страшным. :)
Но «контрольным выстрелом» было то, что в easla.com уже был реализован процесс Переписка, а также Договора, Заказчики и прочие сопутствующие. Поэтому Задачи явились логичным продолжением. Важным критерием является гибкость системы. Как я упомянул в статье, задачи в окончательном виде родились не сразу. Сперва были простенькими, потом становились все сложнее и сложнее. Такой эволюционный процесс очень полезен для пользователей и не очень удобен для разработчика.
И да, было желание «создать свое», но я стараюсь быть объективным в своих желаниях.
Почему же так скептично?
Мой опыт показывает, что любая система документооборота постепенно обрастает новыми решениями. Вопрос упирается только в ее гибкость и, как бы, «легкочитаемость». Тогда поддерживать и развивать ее несложно.
Насчет «открытости», всегда считал, что «открытость» системы определяется наличием API и поддержкой различных протоколов обмена данными, например, SOAP, а не передачей исходного кода клиенту.
Мой жизненный опыт уже научил меня, что нет проектных организаций с одинаковыми бизнес-процессами. Каждой надо «шить на заказ». А в этом случае, нужен не коробочный продукт, а платформа с готовыми шаблонами процессов, которые изначально предполагают, что их не станут использовать «как есть», а скопируют и «допилят» под себя. Коей easla.com и является. Я свой процесс Задачи опубликовал для общего использования. Кто захочет, сможет его заимствовать и заточить под себя. Равно как и я когда-нибудь, когда пойду работать в другую организацию :)
Кстати, насчет непохожести. Есть ГОСТ 21.1101-2013, единый для всех проектных организаций. Регламентирует правила оформления проектной документации в организациях по всей России. Но даже в организациях находящихся в границах шести кварталов нашего города оформляют документацию по-разному, хотя вся она соответствует ГОСТ. Парадокс. :)
Насчет «best practice» (лучших практик). Как показывает мой жизненный опыт, с ними нужно быть поосторожнее. Изучать лучшие практики нужно и полезно (ITIL, PM BOK, CobiT), но тупой перенос их в работу, не оглядываясь на окружающую действительность, может только ухудшить ситуацию.
Конкретный пример из жизни. Недавно на хабре была статья о ревизиях. Ревизии — яркий пример «best practice». Они активно используются на «западе». Ревизии в целом — отличный способ контролировать процесс разработки проектной документации. В нашем ГОСТ нет такого понятия. Есть только изменения, которые позволяют контролировать только процесс изменения документации после сдачи в архив, но вот до этого момента, процедуры не регламентированы. В общем, ревизии — классная штука, если пользоваться ими правильно!
Но их начинают использовать сейчас все кому не лень и совершенно бездумно. Ревизии заменяют изменения в наше ГОСТ. Но наш ГОСТ никто не отменял. В итоге, и ревизии по стандартам «западных» и «прозападных» компаний, и изменения по ГОСТ приходится применять одновременно! Это вносит не просто путаницу, а порой полное непонимание, что и как идентифицировать и в какой момент. И не только на стороне исполнителя, но и на стороне заказчика. Таким образом, великолепный и признанный во всем мире «best practice» не только не помогает в работе, а напротив, тормозит ее, снижает эффективность и прозрачность.
По хорошему, надо было на уровне министерства или как они там сейчас называются, внести изменения в ГОСТ. Отменить изменения, вместо них описать работу с ревизиями и все! Было бы здорово!
Кроме этого существует понятие «зрелость процесса» и «зрелость компании». Многие «best practice» предполагают довольно высокую зрелость и того и другого, поэтому их запуск в «недозрелой» компании создаст больше вопросов, чем решений. Реализация же бизнес-процесса в точности по требованиям самой компании и быстрее и понятнее конечным пользователям от главного инженера, до техника.
Про SAP на хабре тоже недавно была «хвалебная» статья только подтверждающая опасения многих.
Кстати, не стоит забывать и про финансовую составляющую. Продукты 1С и уж тем более SAP имеют такой ценник, что в условиях современного кризиса их просто не потянуть, а easla.com почти бесплатная!
P.S. Таким же образом однажды воспользовался доступом к официальной переписке и отправил несколько официальных писем прямо со своей соты.
После неудачных попыток поискали другие. Системы, которые описывают свою бизнес-логику «кликами мышки» меня разочаровали. Верить в их возможности я перестал. К моменту, когда определились финансовая ситуация в организации стала такой, что покупать что-то было нереально.
Как указывал выше, важным критерием была гибкость системы, а easla.com позволяет описывать процессы кодом — куда уж гибче! Пусть нет блок-схем, но зато логика поведения точно такая, какая нужна.
Все задачи не относящиеся к проектным договорам проходят по так называемым «внутренним договорам». Нарочно созданы договоры «100» и «200» по которым выполняются внутренние задачи. Никаких проблем.
Спасибо за оценку моих трудов!
И, кстати, не стоит забывать про финансовую составляющую. Сколько будет стоить Лоцман ПГС или его аналоги, и во сколько обойдется easla.com.
По поводу «жизнь… упростилась», вы правы. Инструмент был нужен в первую очередь главному инженеру, о чем я сказал в статье. Суть в том, что именно главный инженер наиболее организованный сотрудник компании и с мощной внутренней мотивацией. Его прямые подчиненные — ГИПы, по больше части уже не так заинтересованы в существовании автоматизированного механизма управления задачами. Им удобнее сослаться на плохую память, занятость, невозможность исполнения и прочее, чем выстроить под собой процесс исполнения поручений. Собственно с этим и начал бороться главный инженер сменив прежнего.
Объективным доказательством сказанного является тот факт, что до смены главного инженера ни один ГИП, ни разу не пришел и не попросил хоть какую-то систему управления задачами. Даже в sharepoint или outlook!
Сейчас, пусть не все задачи исполняются в срок, но они по крайней мере уже не забываются, не закрываются безосновательно и будут выполнены все равно хоть и со срывом сроков. Такого раньше не было. Поручения могли просто «похоронить» и «воскресали» они только когда звонил злой заказчик и требовал о нем вспомнить!
Насчет самодурства, сомневаюсь, т.к. знаю его лично. Количество задач 15-20 в день для коллектива в 200 человек с минимальным сроком выполнения 8 часов (а обычно 40 часов) — пшик! Не вижу препятствий выполнять все в срок!
Кстати, как указано в статье, вид «Авторский надзор» оказался крайне необходимым. Раньше подобный отчет ГИП собирал вручную и мог тратить на это неделю! Конечно, не 40 часов, но пока получит от каждого данные, пока сведет их вместе, пока сформирует смету… Таким образом запрошенная в понедельник смета могла попасть заказчику только в конце недели, а то и вовсе не попасть и из-за этого теряли деньги. Сейчас смета формируется на основании отчета в течении секунд 20 + время на фильтр к виду. На все про все минуты 2! Так что, считаю, что автоматизация управления задачами получилась не надуманной. И даже с реальной, а не потенциальной, экономической выгодой.
В том случае, когда первая система «упирается в потолок», ее поддержит вторая. И наоборот.
Об интеграции с Exchange пока речь не шла, а вот об отображении задач в виде диаграмм Гантта — да.
По опыту, например, для управления проектной документацией с момента создания и до момента сдачи в архив используется TDMS. На рынке полно «коробочных» продуктов, которые по стартовым возможностям превосходят TDMS. Однако, несколько лет назад мы все равно выбрали TDMS. Почему? Потому организации с абсолютно одинаковыми процессами встречаются нечасто. Правильнее сказать, организации с одинаковыми (типовыми) процессами бывают при условии, что работают в определенной нише, в которой процессы «устаканились» уже давным давно. Такие организации могут позволить себе «коробочные» или готовые облачные и онлайн сервисы с преднастроенными бизнес-процессами. Зарегистрировался. Добавил пользователей. Начал работать.
В нашем случае так не получается, т.к. бизнес-процессы компании не соответствуют никаким стандартам. Их надо «шить на заказ». Поэтому нужна не «смесь» нескольких продуктов, а платформа, на которой можно «замесить» несколько процессов разом.
Конечно, не исключаю вопросы интеграции. Но, как бы, по-крупному. Мы уже такой опыт поимели. TDMS скрещена с easla.com. TDMS скрещена с Outlook и Exchange. И easla.com умеет интегрироваться с LDAP.
Кроме этого, как уже написал выше, имеет значение гибкость системы. Возможность оперативно подстроиться под новые требования без остановки производства даже на 5 минут. Добавил атрибут. Описал логику и сразу в бой!
Недавно, примерно месяц назад, приезжал представитель одного заказчика и попросил провести ему экскурсию. Позадавал вопросы на местах. Дошел до ГИПа и попросил показать список задач по его проектам. А он у него весь красный! Не столько потому, что задачи не выполнены, сколько потому, что он их банально не закрыл вовремя, хотя все сделал! Крику было!
В общем, исполнительская дисциплина потихоньку перестает хромать. Эволюция…
Например, при отправке исходящего письма происходит автоматическое комментирование задач, на основании которых оно (письмо) и появилось! Не знаю, на сколько такое возможно в Redmine.
В Jira есть возможность кроме задач управлять еще корреспонденцией (входящие и исходящие), договорами, заказчиками, инцидентами, изменениями, нормативной документацией, согласованиями? Навскидку.
Но «контрольным выстрелом» было то, что в easla.com уже был реализован процесс Переписка, а также Договора, Заказчики и прочие сопутствующие. Поэтому Задачи явились логичным продолжением. Важным критерием является гибкость системы. Как я упомянул в статье, задачи в окончательном виде родились не сразу. Сперва были простенькими, потом становились все сложнее и сложнее. Такой эволюционный процесс очень полезен для пользователей и не очень удобен для разработчика.
И да, было желание «создать свое», но я стараюсь быть объективным в своих желаниях.
Мой опыт показывает, что любая система документооборота постепенно обрастает новыми решениями. Вопрос упирается только в ее гибкость и, как бы, «легкочитаемость». Тогда поддерживать и развивать ее несложно.