Comments 37
Вот так онлайн система документооборота и превращается или в монструозный конструктор, или в не понятно что…
Почему же так скептично?
Мой опыт показывает, что любая система документооборота постепенно обрастает новыми решениями. Вопрос упирается только в ее гибкость и, как бы, «легкочитаемость». Тогда поддерживать и развивать ее несложно.
Мой опыт показывает, что любая система документооборота постепенно обрастает новыми решениями. Вопрос упирается только в ее гибкость и, как бы, «легкочитаемость». Тогда поддерживать и развивать ее несложно.
Любая узкоспециализированная система рано или поздно понимает что упирается в потолок своей специфики и понимает что чего-то не хватает… И делает решение внутри себя. Ну и да. Гибкость и легкочитаемость закончится, когда к задачам добавятся обсуждения, привязки документов, сроки, отчеты, интеграции с эксченжем (надо ведь задачи с аутлуком синхронизировать?) и т.д.
Я здесь немного ниже описал, что в описанной организации используется еще одна система — TDMS. Между TDMS и easla.com проведена условная черта ответственности. В TDMS вся проектная документация — весь ее жизненный цикл. В easla.com вся организационно-распорядительная документация и управления.
В том случае, когда первая система «упирается в потолок», ее поддержит вторая. И наоборот.
Об интеграции с Exchange пока речь не шла, а вот об отображении задач в виде диаграмм Гантта — да.
В том случае, когда первая система «упирается в потолок», ее поддержит вторая. И наоборот.
Об интеграции с Exchange пока речь не шла, а вот об отображении задач в виде диаграмм Гантта — да.
А чем Вас неустроили уже написанные Bug треккеры?
Или просто захотели создать свое?
Или просто захотели создать свое?
Эээ… багтрекеры? В статье я же указал, что речь идет о проектной организации. Понимаю, что слово «проект» в современном обществе очень широкого понятия, поэтому уточню. Проектная организация — разработка проектов обустройства нефтегазовых месторождений. Сотрудниками организации являются инженеры, которые про багтрекеры слыхом не слыхивали. Попытаться затащить их в такую систему мне кажется уже страшным. :)
Но «контрольным выстрелом» было то, что в easla.com уже был реализован процесс Переписка, а также Договора, Заказчики и прочие сопутствующие. Поэтому Задачи явились логичным продолжением. Важным критерием является гибкость системы. Как я упомянул в статье, задачи в окончательном виде родились не сразу. Сперва были простенькими, потом становились все сложнее и сложнее. Такой эволюционный процесс очень полезен для пользователей и не очень удобен для разработчика.
И да, было желание «создать свое», но я стараюсь быть объективным в своих желаниях.
Но «контрольным выстрелом» было то, что в easla.com уже был реализован процесс Переписка, а также Договора, Заказчики и прочие сопутствующие. Поэтому Задачи явились логичным продолжением. Важным критерием является гибкость системы. Как я упомянул в статье, задачи в окончательном виде родились не сразу. Сперва были простенькими, потом становились все сложнее и сложнее. Такой эволюционный процесс очень полезен для пользователей и не очень удобен для разработчика.
И да, было желание «создать свое», но я стараюсь быть объективным в своих желаниях.
Например Jira — очень похоже на то, что вы сами реализовали. Плюс у нее есть поддержка плагинов.
Одна из целей — реализация всех бизнес-процессов на единой платформе.
В Jira есть возможность кроме задач управлять еще корреспонденцией (входящие и исходящие), договорами, заказчиками, инцидентами, изменениями, нормативной документацией, согласованиями? Навскидку.
В Jira есть возможность кроме задач управлять еще корреспонденцией (входящие и исходящие), договорами, заказчиками, инцидентами, изменениями, нормативной документацией, согласованиями? Навскидку.
Смотря что понимать под управлением. Особенно интересно — управление Заказчиками.
У нас управление договорами, изменениями, нормативкой и согласованиями ведется в Jira (настроены разные жизненные циклы процессов на разные проекты)
У нас управление договорами, изменениями, нормативкой и согласованиями ведется в Jira (настроены разные жизненные циклы процессов на разные проекты)
Т.е. Вам нужна некая смесь ERP+Redmine? Из легко поддающихся кастомизации Вам бы подошла Odoo, но она почему-то в РФ не популярна.
Скорее всего нужна не гремучая смесь, а платформа.
По опыту, например, для управления проектной документацией с момента создания и до момента сдачи в архив используется TDMS. На рынке полно «коробочных» продуктов, которые по стартовым возможностям превосходят TDMS. Однако, несколько лет назад мы все равно выбрали TDMS. Почему? Потому организации с абсолютно одинаковыми процессами встречаются нечасто. Правильнее сказать, организации с одинаковыми (типовыми) процессами бывают при условии, что работают в определенной нише, в которой процессы «устаканились» уже давным давно. Такие организации могут позволить себе «коробочные» или готовые облачные и онлайн сервисы с преднастроенными бизнес-процессами. Зарегистрировался. Добавил пользователей. Начал работать.
В нашем случае так не получается, т.к. бизнес-процессы компании не соответствуют никаким стандартам. Их надо «шить на заказ». Поэтому нужна не «смесь» нескольких продуктов, а платформа, на которой можно «замесить» несколько процессов разом.
Конечно, не исключаю вопросы интеграции. Но, как бы, по-крупному. Мы уже такой опыт поимели. TDMS скрещена с easla.com. TDMS скрещена с Outlook и Exchange. И easla.com умеет интегрироваться с LDAP.
Кроме этого, как уже написал выше, имеет значение гибкость системы. Возможность оперативно подстроиться под новые требования без остановки производства даже на 5 минут. Добавил атрибут. Описал логику и сразу в бой!
По опыту, например, для управления проектной документацией с момента создания и до момента сдачи в архив используется TDMS. На рынке полно «коробочных» продуктов, которые по стартовым возможностям превосходят TDMS. Однако, несколько лет назад мы все равно выбрали TDMS. Почему? Потому организации с абсолютно одинаковыми процессами встречаются нечасто. Правильнее сказать, организации с одинаковыми (типовыми) процессами бывают при условии, что работают в определенной нише, в которой процессы «устаканились» уже давным давно. Такие организации могут позволить себе «коробочные» или готовые облачные и онлайн сервисы с преднастроенными бизнес-процессами. Зарегистрировался. Добавил пользователей. Начал работать.
В нашем случае так не получается, т.к. бизнес-процессы компании не соответствуют никаким стандартам. Их надо «шить на заказ». Поэтому нужна не «смесь» нескольких продуктов, а платформа, на которой можно «замесить» несколько процессов разом.
Конечно, не исключаю вопросы интеграции. Но, как бы, по-крупному. Мы уже такой опыт поимели. TDMS скрещена с easla.com. TDMS скрещена с Outlook и Exchange. И easla.com умеет интегрироваться с LDAP.
Кроме этого, как уже написал выше, имеет значение гибкость системы. Возможность оперативно подстроиться под новые требования без остановки производства даже на 5 минут. Добавил атрибут. Описал логику и сразу в бой!
Изобрели редмайн )
Если смотреть с точки зрения только управления задачами, то наверное вы правы. Мне было важно интегрировать вроде как самостоятельный процесс управления задачами с кучкой других процессов, в частности, корреспонденцией и договорами. Все задачки привязаны к договорами и письмам. Кроме этого, как я описал в статье, интеграция очень тесная.
Например, при отправке исходящего письма происходит автоматическое комментирование задач, на основании которых оно (письмо) и появилось! Не знаю, на сколько такое возможно в Redmine.
Например, при отправке исходящего письма происходит автоматическое комментирование задач, на основании которых оно (письмо) и появилось! Не знаю, на сколько такое возможно в Redmine.
Ну не только redmine если смотреть шире то есть еще: solutions.1c.ru/catalog/project-org/features
В отличии от примера из статьи (где описывается воплощение фантазий конкретного руководителя) в решении от 1С примерены «Best practice» (как любят говорить коллеги из SAP).
Все что перечислили в этих системах есть (и даже больше).
Но для внедрения подобного потребуется гораздо больше всего (времени, денег, знаний).
В отличии от примера из статьи (где описывается воплощение фантазий конкретного руководителя) в решении от 1С примерены «Best practice» (как любят говорить коллеги из SAP).
Все что перечислили в этих системах есть (и даже больше).
Но для внедрения подобного потребуется гораздо больше всего (времени, денег, знаний).
Немного ниже упоминали 1С, но когда я лично изучал возможности продуктов 1С, то заметил, что они не умеют хранить файлы. Это был большой минус. Не знаю как сейчас, возможно ситуация изменилась. Вы в курсе?
Насчет «best practice» (лучших практик). Как показывает мой жизненный опыт, с ними нужно быть поосторожнее. Изучать лучшие практики нужно и полезно (ITIL, PM BOK, CobiT), но тупой перенос их в работу, не оглядываясь на окружающую действительность, может только ухудшить ситуацию.
Конкретный пример из жизни. Недавно на хабре была статья о ревизиях. Ревизии — яркий пример «best practice». Они активно используются на «западе». Ревизии в целом — отличный способ контролировать процесс разработки проектной документации. В нашем ГОСТ нет такого понятия. Есть только изменения, которые позволяют контролировать только процесс изменения документации после сдачи в архив, но вот до этого момента, процедуры не регламентированы. В общем, ревизии — классная штука, если пользоваться ими правильно!
Но их начинают использовать сейчас все кому не лень и совершенно бездумно. Ревизии заменяют изменения в наше ГОСТ. Но наш ГОСТ никто не отменял. В итоге, и ревизии по стандартам «западных» и «прозападных» компаний, и изменения по ГОСТ приходится применять одновременно! Это вносит не просто путаницу, а порой полное непонимание, что и как идентифицировать и в какой момент. И не только на стороне исполнителя, но и на стороне заказчика. Таким образом, великолепный и признанный во всем мире «best practice» не только не помогает в работе, а напротив, тормозит ее, снижает эффективность и прозрачность.
По хорошему, надо было на уровне министерства или как они там сейчас называются, внести изменения в ГОСТ. Отменить изменения, вместо них описать работу с ревизиями и все! Было бы здорово!
Кроме этого существует понятие «зрелость процесса» и «зрелость компании». Многие «best practice» предполагают довольно высокую зрелость и того и другого, поэтому их запуск в «недозрелой» компании создаст больше вопросов, чем решений. Реализация же бизнес-процесса в точности по требованиям самой компании и быстрее и понятнее конечным пользователям от главного инженера, до техника.
Про SAP на хабре тоже недавно была «хвалебная» статья только подтверждающая опасения многих.
Кстати, не стоит забывать и про финансовую составляющую. Продукты 1С и уж тем более SAP имеют такой ценник, что в условиях современного кризиса их просто не потянуть, а easla.com почти бесплатная!
Насчет «best practice» (лучших практик). Как показывает мой жизненный опыт, с ними нужно быть поосторожнее. Изучать лучшие практики нужно и полезно (ITIL, PM BOK, CobiT), но тупой перенос их в работу, не оглядываясь на окружающую действительность, может только ухудшить ситуацию.
Конкретный пример из жизни. Недавно на хабре была статья о ревизиях. Ревизии — яркий пример «best practice». Они активно используются на «западе». Ревизии в целом — отличный способ контролировать процесс разработки проектной документации. В нашем ГОСТ нет такого понятия. Есть только изменения, которые позволяют контролировать только процесс изменения документации после сдачи в архив, но вот до этого момента, процедуры не регламентированы. В общем, ревизии — классная штука, если пользоваться ими правильно!
Но их начинают использовать сейчас все кому не лень и совершенно бездумно. Ревизии заменяют изменения в наше ГОСТ. Но наш ГОСТ никто не отменял. В итоге, и ревизии по стандартам «западных» и «прозападных» компаний, и изменения по ГОСТ приходится применять одновременно! Это вносит не просто путаницу, а порой полное непонимание, что и как идентифицировать и в какой момент. И не только на стороне исполнителя, но и на стороне заказчика. Таким образом, великолепный и признанный во всем мире «best practice» не только не помогает в работе, а напротив, тормозит ее, снижает эффективность и прозрачность.
По хорошему, надо было на уровне министерства или как они там сейчас называются, внести изменения в ГОСТ. Отменить изменения, вместо них описать работу с ревизиями и все! Было бы здорово!
Кроме этого существует понятие «зрелость процесса» и «зрелость компании». Многие «best practice» предполагают довольно высокую зрелость и того и другого, поэтому их запуск в «недозрелой» компании создаст больше вопросов, чем решений. Реализация же бизнес-процесса в точности по требованиям самой компании и быстрее и понятнее конечным пользователям от главного инженера, до техника.
Про SAP на хабре тоже недавно была «хвалебная» статья только подтверждающая опасения многих.
Кстати, не стоит забывать и про финансовую составляющую. Продукты 1С и уж тем более SAP имеют такой ценник, что в условиях современного кризиса их просто не потянуть, а easla.com почти бесплатная!
А менеджеры в кулуарах не возмущаются инструментом, который наглядно демонстрирует их полную бесполезность?
Я вам больше скажу! Они не только возмущаются, но и стонут, когда главный инженер «спускает собак» и заставляет навести порядок в задачах.
Недавно, примерно месяц назад, приезжал представитель одного заказчика и попросил провести ему экскурсию. Позадавал вопросы на местах. Дошел до ГИПа и попросил показать список задач по его проектам. А он у него весь красный! Не столько потому, что задачи не выполнены, сколько потому, что он их банально не закрыл вовремя, хотя все сделал! Крику было!
В общем, исполнительская дисциплина потихоньку перестает хромать. Эволюция…
Недавно, примерно месяц назад, приезжал представитель одного заказчика и попросил провести ему экскурсию. Позадавал вопросы на местах. Дошел до ГИПа и попросил показать список задач по его проектам. А он у него весь красный! Не столько потому, что задачи не выполнены, сколько потому, что он их банально не закрыл вовремя, хотя все сделал! Крику было!
В общем, исполнительская дисциплина потихоньку перестает хромать. Эволюция…
Из приведенного текста не заметно, что развернутая система упрощает жизнь ГИПов. Несмотря на красные задачи, производственный процесс, судя по всему, успешно работает.
А вот жизнь главного инженера да, скорее всего упростилась, но целью добавления временных затрат подчиненных. И я бы не был настолько оптимистичен, утверждая, что процесс успешно автоматизирован, так как его внедрение происходит административными методами.
Похоже, что главный инженер уже сразу предложил решение, которое, по его мнению, поможет снизить количество неисполненных задач, а исходную проблему так и не попытались найти. По крайней мере, в статье об этом нет ни слова.
Но проблема может быть совсем другой. Например, что главный инженер-самодур, раздает по 15 незначительных задач в день (по 2 в час!) и заставляет по ним отчитываться, а каждый отчет требует у подчиненных 15-20 минут на подготовку. Поэтому сотрудники такие задачи не любят и саботируют их. В этом случае и решение, скорее всего, было бы совсем другое, и не лежащее в области автоматизации.
А вот жизнь главного инженера да, скорее всего упростилась, но целью добавления временных затрат подчиненных. И я бы не был настолько оптимистичен, утверждая, что процесс успешно автоматизирован, так как его внедрение происходит административными методами.
Похоже, что главный инженер уже сразу предложил решение, которое, по его мнению, поможет снизить количество неисполненных задач, а исходную проблему так и не попытались найти. По крайней мере, в статье об этом нет ни слова.
Но проблема может быть совсем другой. Например, что главный инженер-самодур, раздает по 15 незначительных задач в день (по 2 в час!) и заставляет по ним отчитываться, а каждый отчет требует у подчиненных 15-20 минут на подготовку. Поэтому сотрудники такие задачи не любят и саботируют их. В этом случае и решение, скорее всего, было бы совсем другое, и не лежащее в области автоматизации.
Вопрос оптимизации и автоматизации все-таки в разных плоскостях. В статье описывается второе.
По поводу «жизнь… упростилась», вы правы. Инструмент был нужен в первую очередь главному инженеру, о чем я сказал в статье. Суть в том, что именно главный инженер наиболее организованный сотрудник компании и с мощной внутренней мотивацией. Его прямые подчиненные — ГИПы, по больше части уже не так заинтересованы в существовании автоматизированного механизма управления задачами. Им удобнее сослаться на плохую память, занятость, невозможность исполнения и прочее, чем выстроить под собой процесс исполнения поручений. Собственно с этим и начал бороться главный инженер сменив прежнего.
Объективным доказательством сказанного является тот факт, что до смены главного инженера ни один ГИП, ни разу не пришел и не попросил хоть какую-то систему управления задачами. Даже в sharepoint или outlook!
Сейчас, пусть не все задачи исполняются в срок, но они по крайней мере уже не забываются, не закрываются безосновательно и будут выполнены все равно хоть и со срывом сроков. Такого раньше не было. Поручения могли просто «похоронить» и «воскресали» они только когда звонил злой заказчик и требовал о нем вспомнить!
Насчет самодурства, сомневаюсь, т.к. знаю его лично. Количество задач 15-20 в день для коллектива в 200 человек с минимальным сроком выполнения 8 часов (а обычно 40 часов) — пшик! Не вижу препятствий выполнять все в срок!
Кстати, как указано в статье, вид «Авторский надзор» оказался крайне необходимым. Раньше подобный отчет ГИП собирал вручную и мог тратить на это неделю! Конечно, не 40 часов, но пока получит от каждого данные, пока сведет их вместе, пока сформирует смету… Таким образом запрошенная в понедельник смета могла попасть заказчику только в конце недели, а то и вовсе не попасть и из-за этого теряли деньги. Сейчас смета формируется на основании отчета в течении секунд 20 + время на фильтр к виду. На все про все минуты 2! Так что, считаю, что автоматизация управления задачами получилась не надуманной. И даже с реальной, а не потенциальной, экономической выгодой.
По поводу «жизнь… упростилась», вы правы. Инструмент был нужен в первую очередь главному инженеру, о чем я сказал в статье. Суть в том, что именно главный инженер наиболее организованный сотрудник компании и с мощной внутренней мотивацией. Его прямые подчиненные — ГИПы, по больше части уже не так заинтересованы в существовании автоматизированного механизма управления задачами. Им удобнее сослаться на плохую память, занятость, невозможность исполнения и прочее, чем выстроить под собой процесс исполнения поручений. Собственно с этим и начал бороться главный инженер сменив прежнего.
Объективным доказательством сказанного является тот факт, что до смены главного инженера ни один ГИП, ни разу не пришел и не попросил хоть какую-то систему управления задачами. Даже в sharepoint или outlook!
Сейчас, пусть не все задачи исполняются в срок, но они по крайней мере уже не забываются, не закрываются безосновательно и будут выполнены все равно хоть и со срывом сроков. Такого раньше не было. Поручения могли просто «похоронить» и «воскресали» они только когда звонил злой заказчик и требовал о нем вспомнить!
Насчет самодурства, сомневаюсь, т.к. знаю его лично. Количество задач 15-20 в день для коллектива в 200 человек с минимальным сроком выполнения 8 часов (а обычно 40 часов) — пшик! Не вижу препятствий выполнять все в срок!
Кстати, как указано в статье, вид «Авторский надзор» оказался крайне необходимым. Раньше подобный отчет ГИП собирал вручную и мог тратить на это неделю! Конечно, не 40 часов, но пока получит от каждого данные, пока сведет их вместе, пока сформирует смету… Таким образом запрошенная в понедельник смета могла попасть заказчику только в конце недели, а то и вовсе не попасть и из-за этого теряли деньги. Сейчас смета формируется на основании отчета в течении секунд 20 + время на фильтр к виду. На все про все минуты 2! Так что, считаю, что автоматизация управления задачами получилась не надуманной. И даже с реальной, а не потенциальной, экономической выгодой.
Я скажу больше — все зависит от внутренней культуры компании и от того, куда ее ведут. Вы совершенно правы в том, что административные методы редко приводят к идеальному результату. В таком случае ГИ практически всегда назначают «самодуром». Но в случае, когда задачи ставятся, но не выполняются, выход только один — все-таки ввести учет.
Из-за чего задачи не выполняются — это, действительно, другой вопрос. Тут поможет анализ накопленных данных. Может получиться так, что причина — бешеная загрузка. Может — просто «тихий саботаж». Может — еще что-то. И в каждом случае рецепт исправления — свой, но в основе возможности анализа — учет. Наша задача — предоставить соответствующий инструмент. С возможностью его развития в любую сторону.
Из-за чего задачи не выполняются — это, действительно, другой вопрос. Тут поможет анализ накопленных данных. Может получиться так, что причина — бешеная загрузка. Может — просто «тихий саботаж». Может — еще что-то. И в каждом случае рецепт исправления — свой, но в основе возможности анализа — учет. Наша задача — предоставить соответствующий инструмент. С возможностью его развития в любую сторону.
Я вам завидую изо всех сил. В моей последней организации, которую очень любят вспоминать на хабре, исключительно массовой практикой среди всех руководителей было вообще никогда принципиально не читать почту, уведомления и не отвечать на звонки. Срочные тикеты, по которым время реакции было установлено вендором в сутки, согласовывались годами, а не срочные — вообще никогда. Высшее руководство их в этом активно поддерживало, а тех, кто пытался напоминать о том, что хорошо бы всё-таки провести запланированные работы — довольно быстро изгоняли из компании.
Вспомнился первый опыт работы с менеджерами задач лет 15 назад. Ах, что были за времена :-)
Такое подбираются под пользователя, его видение процесса. Также как стул, ручка…
Вы изобрели 1С Документооборот.
Там есть всё что вы реализовали + немного ещё.
Понятно что вам может претить сама фирма 1С, но имеет смысл посмотреть что реализовано у 1С — возможно у вас появятся идеи что можно добавить у себя.
Там есть всё что вы реализовали + немного ещё.
Понятно что вам может претить сама фирма 1С, но имеет смысл посмотреть что реализовано у 1С — возможно у вас появятся идеи что можно добавить у себя.
Статья о том, как заново изобрели велосипед =) Сколько уже понаделано такого 100 % одинакового за последние 15-20 лет =) Посмотрите хотя бы в сторону Лоцман ПГС и плагинов к нему и т.д.
Идея для «киллер» фичи, которая будет выгодно отличать продукт от других: на основе собранных данных о выполненных проектах, автоматизированно создавать справочник норм труда/материалов. Далее в системе появится возможность делать прогнозы для того или иного развития событий проекта.
Идея для «киллер» фичи, которая будет выгодно отличать продукт от других: на основе собранных данных о выполненных проектах, автоматизированно создавать справочник норм труда/материалов. Далее в системе появится возможность делать прогнозы для того или иного развития событий проекта.
Вот только не Лоцман. Дурная весть за ним идет. Лично дело не имел, но коллеги с других организаций отзывают не очень лестно.
И, кстати, не стоит забывать про финансовую составляющую. Сколько будет стоить Лоцман ПГС или его аналоги, и во сколько обойдется easla.com.
И, кстати, не стоит забывать про финансовую составляющую. Сколько будет стоить Лоцман ПГС или его аналоги, и во сколько обойдется easla.com.
Лоцман был дан в качестве примера. Не реклама. Ну а так — на вкус и цвет товарища нет =)
В этом продукте очень хорошо проработана автоматизация всей проектной деятельности (строительство) — можно брать смотреть в качестве примера (источника вдохновения для бизнес аналитика).
В этом продукте очень хорошо проработана автоматизация всей проектной деятельности (строительство) — можно брать смотреть в качестве примера (источника вдохновения для бизнес аналитика).
На сколько я знаю, «Лоцман» — коробочный продукт с преднастроенными бизнес-процессами. Изменить готовые процессы в нем не так то просто. Надо или иметь хорошие знания самого продукта, или платить денежки интеграторам. Причем денежки немалые (в одной из знакомых мне организаций на Лоцман потратили несколько миллионов, а «воз и ныне там»).
Мой жизненный опыт уже научил меня, что нет проектных организаций с одинаковыми бизнес-процессами. Каждой надо «шить на заказ». А в этом случае, нужен не коробочный продукт, а платформа с готовыми шаблонами процессов, которые изначально предполагают, что их не станут использовать «как есть», а скопируют и «допилят» под себя. Коей easla.com и является. Я свой процесс Задачи опубликовал для общего использования. Кто захочет, сможет его заимствовать и заточить под себя. Равно как и я когда-нибудь, когда пойду работать в другую организацию :)
Кстати, насчет непохожести. Есть ГОСТ 21.1101-2013, единый для всех проектных организаций. Регламентирует правила оформления проектной документации в организациях по всей России. Но даже в организациях находящихся в границах шести кварталов нашего города оформляют документацию по-разному, хотя вся она соответствует ГОСТ. Парадокс. :)
Мой жизненный опыт уже научил меня, что нет проектных организаций с одинаковыми бизнес-процессами. Каждой надо «шить на заказ». А в этом случае, нужен не коробочный продукт, а платформа с готовыми шаблонами процессов, которые изначально предполагают, что их не станут использовать «как есть», а скопируют и «допилят» под себя. Коей easla.com и является. Я свой процесс Задачи опубликовал для общего использования. Кто захочет, сможет его заимствовать и заточить под себя. Равно как и я когда-нибудь, когда пойду работать в другую организацию :)
Кстати, насчет непохожести. Есть ГОСТ 21.1101-2013, единый для всех проектных организаций. Регламентирует правила оформления проектной документации в организациях по всей России. Но даже в организациях находящихся в границах шести кварталов нашего города оформляют документацию по-разному, хотя вся она соответствует ГОСТ. Парадокс. :)
Выглядит, в целом, неплохо. Тяжело оценить юзабилити и полноту функционала по скринам и тексту, но как старт вполне себе неплохо.
Персонально хочу сказать, что писать свой продукт при наличии уже зарекомендовавших себя на рынке — не самый лучшая идея, т.к. обрастая такими продуктами можно в какой-то момент попасть в точку «невозврата», когда руководство компании не захочет инвестировать в сторонние продукты, даже если они и будут в десятки раз лучше и более подходящими, отмазываясь тем, что «у нас есть свое решение и оно работает». Поэтому я бы для начала оценил рынок коммерческих систем, а после бы уже принимался писать что-то свое, в случае отсутствия чего-то подходящего (во что я не верю). Да, системы нынче стоят мягко говоря немало, но и охватываемая область бизнес-процессов в них зачастую больше, чем компания может себе представить. Опять же Вы отталкивались от требований ГИ и судя по картинкам задачи в основном по договорам, а как же остальные задачи? За ними тоже надо следить и трудозатраты отслеживать… А как же проекты без договора? Например внутренний проект компании? Или концепт?
Но опять же, в рамках поставленной задачи, считаю что решение вполне себе неплохо выглядит. Просто привык думать на перспективу организации в целом, т.к. это зачастую куда более важно чем решение проблемы одного человека или даже целого подразделения.
Персонально хочу сказать, что писать свой продукт при наличии уже зарекомендовавших себя на рынке — не самый лучшая идея, т.к. обрастая такими продуктами можно в какой-то момент попасть в точку «невозврата», когда руководство компании не захочет инвестировать в сторонние продукты, даже если они и будут в десятки раз лучше и более подходящими, отмазываясь тем, что «у нас есть свое решение и оно работает». Поэтому я бы для начала оценил рынок коммерческих систем, а после бы уже принимался писать что-то свое, в случае отсутствия чего-то подходящего (во что я не верю). Да, системы нынче стоят мягко говоря немало, но и охватываемая область бизнес-процессов в них зачастую больше, чем компания может себе представить. Опять же Вы отталкивались от требований ГИ и судя по картинкам задачи в основном по договорам, а как же остальные задачи? За ними тоже надо следить и трудозатраты отслеживать… А как же проекты без договора? Например внутренний проект компании? Или концепт?
Но опять же, в рамках поставленной задачи, считаю что решение вполне себе неплохо выглядит. Просто привык думать на перспективу организации в целом, т.к. это зачастую куда более важно чем решение проблемы одного человека или даже целого подразделения.
Мы уже успели попробовать альтернативный продукт. Боюсь указывать какой, «доброжелатели» заминусуют.
После неудачных попыток поискали другие. Системы, которые описывают свою бизнес-логику «кликами мышки» меня разочаровали. Верить в их возможности я перестал. К моменту, когда определились финансовая ситуация в организации стала такой, что покупать что-то было нереально.
Как указывал выше, важным критерием была гибкость системы, а easla.com позволяет описывать процессы кодом — куда уж гибче! Пусть нет блок-схем, но зато логика поведения точно такая, какая нужна.
Все задачи не относящиеся к проектным договорам проходят по так называемым «внутренним договорам». Нарочно созданы договоры «100» и «200» по которым выполняются внутренние задачи. Никаких проблем.
Спасибо за оценку моих трудов!
После неудачных попыток поискали другие. Системы, которые описывают свою бизнес-логику «кликами мышки» меня разочаровали. Верить в их возможности я перестал. К моменту, когда определились финансовая ситуация в организации стала такой, что покупать что-то было нереально.
Как указывал выше, важным критерием была гибкость системы, а easla.com позволяет описывать процессы кодом — куда уж гибче! Пусть нет блок-схем, но зато логика поведения точно такая, какая нужна.
Все задачи не относящиеся к проектным договорам проходят по так называемым «внутренним договорам». Нарочно созданы договоры «100» и «200» по которым выполняются внутренние задачи. Никаких проблем.
Спасибо за оценку моих трудов!
Оценить юзабилити можете в самой системе заимствуя процесс Задачи себе. Правда, учитывая его тесную интеграцию с другими процессами он может не завестись сразу и придется или поправить самому, или обращаться в техподдержку за помощь.
Интересная тема!
А на мобильных устройствах как это выглядит? Для руководства обычно важен доступ со смартфона.
А на мобильных устройствах как это выглядит? Для руководства обычно важен доступ со смартфона.
Обещали диаграмму Гантта строить по назначенным задачам. Дождались!
Пока в тестовом режиме. Осталось «допилить» верстку и локализацию.
Как-то так:
Кстати, можно отдельную статью написать про «прикручивание» DHTMLX компоненты к Yii.
Пока в тестовом режиме. Осталось «допилить» верстку и локализацию.
Как-то так:
Кстати, можно отдельную статью написать про «прикручивание» DHTMLX компоненты к Yii.
Sign up to leave a comment.
Управление задачами в проектной организации