Мы уже успели попробовать альтернативный продукт. Боюсь указывать какой, «доброжелатели» заминусуют.
После неудачных попыток поискали другие. Системы, которые описывают свою бизнес-логику «кликами мышки» меня разочаровали. Верить в их возможности я перестал. К моменту, когда определились финансовая ситуация в организации стала такой, что покупать что-то было нереально.
Как указывал выше, важным критерием была гибкость системы, а 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 уже был реализован процесс Переписка, а также Договора, Заказчики и прочие сопутствующие. Поэтому Задачи явились логичным продолжением. Важным критерием является гибкость системы. Как я упомянул в статье, задачи в окончательном виде родились не сразу. Сперва были простенькими, потом становились все сложнее и сложнее. Такой эволюционный процесс очень полезен для пользователей и не очень удобен для разработчика.
И да, было желание «создать свое», но я стараюсь быть объективным в своих желаниях.
Почему же так скептично?
Мой опыт показывает, что любая система документооборота постепенно обрастает новыми решениями. Вопрос упирается только в ее гибкость и, как бы, «легкочитаемость». Тогда поддерживать и развивать ее несложно.
Иными словами, в вашем случае, личный календарь позволит ПЛАНИРОВАТЬ, скажем, время устранения инцидента или закрытия задачи, исходя из вашего личного присутствия на рабочем месте. Как-то так:
calendarUserDateAdd($user,$datetime,$seconds);
Теперь понятно.
Спасибо!
Регламент понятен, но вы на вопрос не ответили. Кто отвечает за достоверность данных в личном календаре в вашем случае? Именно ОТВЕЧАЕТ!
Скажем, в личном календаре написано, что Вы отработали 16 часов в выходные и их положено оплатить. Сотрудник отдела кадров или главный бухгалтер берет это обстоятельство под сомнение по каким-то причинам. Кто отвечает в этом случае за то, что указанные в календаре выходные дни для вас на самом деле рабочие и вы действительно отработали 16 часов? Вы? Руководитель?
Отсюда последующий вопрос: у кого, в вашем случае, должны быть права на изменение личного календаря и, собственно, на просмотр тоже.
Идеологический вопрос: кто отвечает за достоверность данных в личном календаре в вашем случае? Сам сотрудник? Сотрудник отдела кадров? Руководитель сотрудника (непосредственный или директор)?
Как вы и написали, изначально мне предлагали много-много строчек кода только ради переименования файла. Мне пришлось указать, как бы это помягче сказать, на нелепость такого решения. В общем, я бился 2 месяца ради вот такого решения:
if (!lastver.File.Name.Equals(fname))
{
lastver.File.Rename(fname);
}
Уверен, и приватные комментарии добавляют мне этой уверенности, что те, кто прочитал статью, выделили из нее «наиболее полезную и ценную» информацию. Благодарен всем, кто подошел к чтению объективно и без эмоций.
Моя цель при разработке easla.com была не столько создать инструмент подвластный мне, сколько подвластный любому. Без оглядок на разработчика. Собственно, и о существовании системы смело заявил только после написания подробного руководства разработчика.
Признаюсь, и я того не скрывал, что за образец для подражания взята TDMS. Некоторые вещи сделаны иначе, например, файловые атрибуты. Кое-что добавлено — например, рабочий календарь, интеграция с почтовой системой.
Нет, не так. Зарегистрировал письмо с номером 11/Аб-1234. Вложил в него файл с именем «файл.doc». Файл должен получить имя «11/Аб-1234.doc». Упс, пришло ценное указание, меняется номер письма, оно станет 11/Ба-4321. Нет проблем. Редактируем объект. Меняется значение атрибута и меняется имя файла на «11/Ба-4321.doc».
Но мне сообщество как «помогло»! Прям закачаешься!
>>Получается, вам было проще разработать свою систему, чем разобраться со своими страхами и производительностью системы?
Поверьте, разбирались и со страхами, и с производительностью. И техподдержка завалена обращениями — 144 тикета. А что толку, если проблема в архитектуре?
Вы же понимаете, что просто так с бухты барахты никто за написание своей PDM системы не берется. Нужен опыт программирования, внедрения, интеграции, работы с системами. И желательно с разными системами. Решающими задачи разных подразделений с разными видами деятельности. В общем, накопилось.
Мой опыт работы с СЭД уже лет 15-16. Разные видел. Разные запускал. Надоело взвешивать преимущества и недостатки. Разумеется, и в easla.com найдутся недостатки, ведь все зависит от требований.
После неудачных попыток поискали другие. Системы, которые описывают свою бизнес-логику «кликами мышки» меня разочаровали. Верить в их возможности я перестал. К моменту, когда определились финансовая ситуация в организации стала такой, что покупать что-то было нереально.
Как указывал выше, важным критерием была гибкость системы, а 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 уже был реализован процесс Переписка, а также Договора, Заказчики и прочие сопутствующие. Поэтому Задачи явились логичным продолжением. Важным критерием является гибкость системы. Как я упомянул в статье, задачи в окончательном виде родились не сразу. Сперва были простенькими, потом становились все сложнее и сложнее. Такой эволюционный процесс очень полезен для пользователей и не очень удобен для разработчика.
И да, было желание «создать свое», но я стараюсь быть объективным в своих желаниях.
Мой опыт показывает, что любая система документооборота постепенно обрастает новыми решениями. Вопрос упирается только в ее гибкость и, как бы, «легкочитаемость». Тогда поддерживать и развивать ее несложно.
calendarUserDateAdd($user,$datetime,$seconds);
Теперь понятно.
Спасибо!
Скажем, в личном календаре написано, что Вы отработали 16 часов в выходные и их положено оплатить. Сотрудник отдела кадров или главный бухгалтер берет это обстоятельство под сомнение по каким-то причинам. Кто отвечает в этом случае за то, что указанные в календаре выходные дни для вас на самом деле рабочие и вы действительно отработали 16 часов? Вы? Руководитель?
Отсюда последующий вопрос: у кого, в вашем случае, должны быть права на изменение личного календаря и, собственно, на просмотр тоже.
if (!lastver.File.Name.Equals(fname))
{
lastver.File.Rename(fname);
}
Уверен, и приватные комментарии добавляют мне этой уверенности, что те, кто прочитал статью, выделили из нее «наиболее полезную и ценную» информацию. Благодарен всем, кто подошел к чтению объективно и без эмоций.
Моя цель при разработке easla.com была не столько создать инструмент подвластный мне, сколько подвластный любому. Без оглядок на разработчика. Собственно, и о существовании системы смело заявил только после написания подробного руководства разработчика.
Признаюсь, и я того не скрывал, что за образец для подражания взята TDMS. Некоторые вещи сделаны иначе, например, файловые атрибуты. Кое-что добавлено — например, рабочий календарь, интеграция с почтовой системой.
Но мне сообщество как «помогло»! Прям закачаешься!
>>Получается, вам было проще разработать свою систему, чем разобраться со своими страхами и производительностью системы?
Поверьте, разбирались и со страхами, и с производительностью. И техподдержка завалена обращениями — 144 тикета. А что толку, если проблема в архитектуре?
Вы же понимаете, что просто так с бухты барахты никто за написание своей PDM системы не берется. Нужен опыт программирования, внедрения, интеграции, работы с системами. И желательно с разными системами. Решающими задачи разных подразделений с разными видами деятельности. В общем, накопилось.
Мой опыт работы с СЭД уже лет 15-16. Разные видел. Разные запускал. Надоело взвешивать преимущества и недостатки. Разумеется, и в easla.com найдутся недостатки, ведь все зависит от требований.