… в котором изложить, что необходимо, чтобы внедрить систему.
и сразу вспомнил случай из своей практики. История с внедрением ERP закончилась именно на этом. Я написал подробный план, передал заказчику, получил положенные деньги. Рассчитывал, что дальше будем работать с заказчиком по этому плану, а он решил передать план своим «айтишникам», дескать дальше пусть они все делают, строго по плану.
На сколько знаю, «воз и ныне там». Уж лет 10 прошло.
Так тоже бывает…
Только надо не забыть, что лед, растаявший на полюсах повысит уровень мирового океана настолько, что ездить на велосипеде станет негде. Нет велосипеда — нет проблем!
Ну, easla.com — это не система учета, а скорее платформа, на которой можно реализовать любые бизнес-процессы организации. И главное реализовать так, как они есть, а не полагаться на «заранее продуманные» и зачастую неподходящие по разным причинам. Конечно, лучшие практики — это хорошо, но вымеренными дозами.
Обратная связь на Битрикс24 в рунете очень познавательная. Порой похожа на «ежики плакали но продолжали жрать кактусы».
Я не против Битрикс24, кому-то ее достаточно, но в нашем случае ее возможностей недостаточно.
Обещали диаграмму Гантта строить по назначенным задачам. Дождались!
Пока в тестовом режиме. Осталось «допилить» верстку и локализацию.
Как-то так:
Кстати, можно отдельную статью написать про «прикручивание» DHTMLX компоненты к Yii.
Мне кажется, что разобраться с API любой системы «программисту средней руки» проще, чем с исходным кодом всей системы. Не так уж много найдется желающих копаться во внутренностях системы, скажем, ради интеграции ее с другой системой, когда надо только организовать передачу значений парочки атрибутов отдельных сущностей.
Разве нет?
«На данный момент самым популярным языком программирования является 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! Так что, считаю, что автоматизация управления задачами получилась не надуманной. И даже с реальной, а не потенциальной, экономической выгодой.
На сколько знаю, «воз и ныне там». Уж лет 10 прошло.
Так тоже бывает…
А управляют нами «смекалистые парни», только их смекалка не в нашу пользу работает… :)
Обратная связь на Битрикс24 в рунете очень познавательная. Порой похожа на «ежики плакали но продолжали жрать кактусы».
Я не против Битрикс24, кому-то ее достаточно, но в нашем случае ее возможностей недостаточно.
Собственно, код системы открытым не является, только компоненты.
P.S. Переход на Yii 2 только в планах.
Пока в тестовом режиме. Осталось «допилить» верстку и локализацию.
Как-то так:
Кстати, можно отдельную статью написать про «прикручивание» DHTMLX компоненты к Yii.
Разве нет?
Насчет «открытости», всегда считал, что «открытость» системы определяется наличием 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! Так что, считаю, что автоматизация управления задачами получилась не надуманной. И даже с реальной, а не потенциальной, экономической выгодой.