На мой взгляд от слова «сервис» для экономики больше вреда :)
А так да, слово «проект» тоже употребляется криво. Обычно имеется ввиду продукт. Если речь идет о неком сайте. Но словосочетание «руководитель продукта» звучит как то ляповато, а «руководитель проекта» как то лучше, вот его и употребляют :)
Как правило такая проблема возникает там где у человека мало кармы чтобы назвать себя предпринимателем, но уже как то называться хочется, потому выбирается такое мало понятное словосочетание.
Конечно это не относится к тем, кто реально рулит проектами, у которых есть срок и ограниченность во всем. Там где надо рвать когти, чтобы закрыть проект в установленный срок.
Подобающее же большинство ошибающихся, свои проекты закрывать не планируют, но один фиг называют их проектами, а себя РП :)
А может сайт веб-сервисов? а может веб-сайт сервисов? :)
Я вот сейчас снова не понял что вы спросили :) и как я должен понять что речь идет о сайте с услугами? а может быть речь идет о WSDL-скрипте? Его также с полным правом можно назвать «веб-сервисом». От куда мне знать что вы сейчас сказали?
И я то ладно, у меня хватит смелости задать вопрос. А вот ее не у всех хватает. Кто то постесняется и промолчит, сделает вид что понял вас, а вы будете думать что будто бы общаетесь с человеком. Хотя на самом деле вы просто издаете звуки, а он просто на вас смотрит. Это называется «делать вид что слушаю».
И одно дело когда речь идет просто о каком то диалоге, где то в тусовке, поболтали или сделали вид что поболтали. Разбежались.
Другое дело когда речь заходит о каких-либо серьезных проектах, где людям нужно общаться, обсуждать задачи и идеи. Вот там пиши пропало. Один выпалил идею, второй сделал вид что понял, а понял все по своему, и пошло поехало… Проект тарабанит из стороны в сторону, потому что люди на разных языках говорят, хотя вроде бы одни слова произносят и пишут.
Да, изменили только стилевые элементы. Так сказать — ходожественную часть.
Дизайн вроде как не трогали, т.к. по большей части он там определен функционалом.
Зашел. Попробовал. Интересно.
1. Адаптивная верстка действительно стала лучше. Заметно лучше.
2. В части цвета — резко. Может быть слишком. Не привычно точно. Нет возможности менять расцветку как раньше. Думаю это изменят.
Сегодня почтовый адрес стал практически заменителем паспорта из физического мира в мире Интернет.
В Google Apps с этим все хорошо. При входе на какой либо сайт я могу предъявить свою запись Google Apps, меня впустят и все будет хорошо.
Это также касается облачных информационных систем уровня предприятия.
По сути OAuth на сегодня это заменитель Active Directory, которым пользовались в старые времена :)
И тот факт что он отсутствует в Я.ПДД — печаль, катастрофа.
По этой причина я пока что сижу на Google Apps. Но с надеждой смотрю в сторону отечественного производителя :)
> Я просто не понял к чему вы привели CasePress в контексте вопроса про то, чем можно заменить 1С.
Никто 1С не заменяет. Просто нет смысла ее дорабатывать под различные процессы обслуживания.
Примеры:
1. Организация занимающаяся обслуживанием компрессоров в УрФО, по 4м регионам РФ. У них БП на 1С, но вот им нужно сделать систему для учета объектов обслуживания (компрессора, насосы, промышленные кондиционеры ...), сделать учет заявок и совместную работу с клиентом. Зачем им дорабатывать 1С? Финансов в этом процессе почти нет, в основном идет учет сообщений и коммуникаций между сотрудниками и клиентом. Это легко настроить на базе CasePress. Дешевле и потом нет проблем с обновлением.
2. СМИ. Выпускает журнал и свой сайт, зарабатывают на рекламе. У них 1С БП 8. CRM на чем то другом. Решили переходить на CasePress, чтобы вести все взаимодействие с клиентом в одной системе. При этом бухгалтер остался на 1С, но получает отчет в в любое время о всех сделках которые подошли к этапу выставления счета, оформляет счет и отправляет, отмечает результат. Здесь данные между системами вносятся руками. Но это не проблема для клиента. Проблемой для него было то что раньше приходилось бегать туда сюда чтобы выставить счет. Сейчас бегать не нужно, т.к. нужная информация на любом рабочем месте доступна по одному щелчку.
3. Крупная контора оказывающая проф услуги. В 20 городах РФ. Под 1000 сотрудников. Процесс «Прием сотрудника». Понятно что он регистрируется в бухгалтерии, но вот стартует он службой персонала. Точнее есть пост «Ответственный за прием». Из за размеров организации, в разных офисах, этот пост занимают разные люди. Где то сам директор филиала, где то юрист, где то офис менеджер, а где то кадровый специалист, если филиал достаточно крупный.
Тут две проблемы:
1. попробуйте ка развернуть 1с на все эти филиалы — уже беда
2. нужно делать кучу настроек, с учетом того что разные типы сотрудников могут иметь этот доступ
3. есть определенные особенности и автоматические сценарии, которые нужно как то делать. В 1С — это опять же придется делать через изменение конфигурации со всеми вытекающими проблемами с дальнейшим обновлением.
В CasePress это делается проще. Добавляется модуль (который как мы знаем живет отдельно от ядра и не влияет на обновление), пишется сценарий, добавляется пост ответственный за прием сотрудников в каждом филиале и на этот пост назначаются люди. Теперь у них появляется право приема сотрудника. Они принимают сотрудников, затем маршрут запускается и данные о сотруднике попадают во все подразделения так или иначе задействованные в приеме. В том числе в бухгалтерию, которая забивает данные в 1С для правильного оформления и регистрации в финансовой системе.
И обратите внимание — процедура очень сложная и запутанная. Ставить каждому сотруднику 1С в этом случае довольно дорого. Еще дороже их потом обучать. И это так или иначе вызывает затраты на изменение 1С — лови потом проблемы с обновлением.
А тут максимально простая система, с привычным интерфейсом, работающая с любого устройства, в т.ч. с мобильного телефона, которая легко ставится на любом рабочем месте в любом филиале, потому что является облаком. Она бесплатна.
И ее можно как угодно модифицировать без боязни за обновления, потому что каждый ее модуль не зависим от ядра. Ядро обновляется, модули продолжают работать.
Я тоже с трудом представляю. И даже писал об этом вот тут habrahabr.ru/post/177235/#comment_6159163
> Лично я придерживаюсь такой идеи, что УПП — это все то что связано с деньгами.
В остальном — я не настаиваю на том что моя идея правильная. Хотел лишь выяснить кто и какие еще идеи использует.
Наш спор ушел в холивар ни о чем. Вы не читаете мои комментарии и начинает спорить сами с собой на тему домыслов из своей же головы.
В таком случае я ничего не смогу до вас донести. Извините.
1. Нужен пример проекта. А так пальцем в небо сложно попасть. Если это медикаменты — 1С Розница Аптека. Могу ошибаться.
Если это ЖКХ, то любая система для документооборота, например ДИРЕКТУМ.
Даже если это строительные проекты, есть специальная 1С УПП для строительства. В любом случае лучше применять что-то готовое, чем изобретать самому.
Если это крайне сложный и запущенный случай, то в любом случае я бы не рискнул править конфигурацию сложного 1С-приложения. Лучше взять что-то, что изначально заточено под такие правки. Например CasePress. Там любые настройки модуля не трогают ядро или другие модули. Обновление ядра или компонента — не затрагивает другие компоненты и может проходить автономно.
Если вы правите 1С УПП, то с выходом новой готовьтесь к пляскам с обновлением. И потратить на это как правило приходится круглую сумму или оставаться без обновления. Такова специфика финансового учета в России.
2. Бывает. Просто если взять проблему 1 и прибавить проблему 2, то произойдет перемножение проблем :) А зачем? Минус одна проблема — в разы проще реализовать проект.
4. Мегаплан как раз хорошо подходит для внедрений. Пока не идет речи о разработке. Наладить нормально процесс разработки в Мегаплане крайне сложно. Сами Мегаплановцы свою разработку ведут в другом продукте. И даже тех поддержку ведут в другом продукте.
А если мы имеем дело со сложными проектам, то управление процессами и проектами в единой среде — очень облегчает жизнь. У меня лично есть опыт создания подобной системы на базе CasePress. Приложение построено по идеологии ACM, позволяет легко адаптироваться под любые бизнес процессы любой сложности и взаимоувязывать их.
При этом если у меня встанет вопрос с финансовым учетом или зарплатой — я лучше возьму 1С, но постараюсь ее не изменять :) Или изменять но как то по минимуму.
1. Это зависит от целей проекта. Если вы хотите все бизнес процессы завязать в УПП — да, придется много дорабатывать. Но это и поднимает затраты, а также начинает зашкаливать риски.
Лично я придерживаюсь такой идеи, что УПП — это все то что связано с деньгами. Какие то обслуживающие бизнес-процессы стараюсь в нее не пихать. Для этого есть более удобные приложения, которые легко интегрировать с БП, КА или УПП. Без внесения изменений в конфигурацию 1С.
2. Я располагаю статистикой, т.к. есть большой опыт работы как на предприятиях, так и в консалтинге, где пришлось повстречаться с убитыми проектами внедрения. Печальное зрелище.
3. Объем работы не маленький — это следствие ошибочных решений. У меня есть опыт внедрения 1С КА 8, за 3 месяца почти в одного, там где до меня целая бригада программистов трудилась более года и не смогли довести проект до результата.
4. Ссылочки имелись ввиду на решения по управлению такими проектами, а не 1С-приложения. С ними хорошо знаком :)
Я не говорю что такие проекты нужно закрывать вообще без доработки. Если опыта хватает — можно.
Но 1С УПП — это относительно зрелый продукт. А преимущество зрелых продуктов в том что их можно внедрять без доработки. Да, это будет не так «удобно», с точки зрения пользователя. Но зато меньше рисков. Рисков, когда проект вылетает за все мыслимые бюджет и сроки.
Думаю мы не будем спорить о том что большая часть проектов внедрения 1С УПП провальны? + затягиваются на годы.
Для себя выработал вот такие правила. Поделился точкой зрения.
Если есть другие решения — ссылочку пожалуйста. С удовольствием почитаю.
Также стоим перед выбором. WebDAV или GIT?
У нас одним из камней является важность версионирования.
Текущая система хранения документов позволяет создавать версии, но не позволяет править файлы прямо на сервере. Приходится скачивать, а потом закачивать обратно. Это проблема.
Наслышаны о WebDAV и его возможности работать с версиями, но в Яндекс.Диске эта возможность отсутствует. Было бы интересно раскрыть эту часть. Планировали? Решали? Разбирали?
1. С утра также был ошарашен.
2. Где то к обеду получил 2хСчастья за счет того что открыл для себя feedly.com
3. Вообще удивился, как раньше его не замечал?
Какой там Google Reader? Давай досвидания!
Иррационализм — это один из методов восприятия реальности. У него есть плюсы относительно рационализма. Но и минусы.
Алгоритм примерно такой: пробуем поставить и описать задачу. Рационалам — это просто. Иррационалы — начнут буксовать.
1. Если видим рациональный подход — работаем стандартно по ТЗ, сроку и бюджету.
2. Если видим иррациональный подход, меняем схему:
2.1. поддерживаем заказчика в части идеи «тут все не продумать, четкое ТЗ описать сложно, нужно будет над этим много поработать» — это их стиль, ничего не попишешь.
2.2. но обосновываем спецификой такого подхода, предлагаем оплату по периодам (неделя, месяц ...) исходя из прогноза частоты встречь
2.3. плюс обозначаем бонус по завершению
Суть:
п.2.3. — должен защитить заказчика от пробуксовок со стороны исполнителя (бонус хочется) и мотивирует сторону исполнителя на закрытие (чем быстрее закончим тем быстрее получим бонус)
п.2.2. — защищает затраты исполнителя и при этом мотивирует заказчика на завершения (каждая итерация увеличивает его затраты)
При этом обе стороны могут работать в максимально надежных условиях, с мотивацией и защитой.
Иррационалов как правило такой подход устраивает, т.к. они сами не очень то любят работать в сроках и рамках. Такова их природа. Потому они чаще на это идут чем рационалы.
Да, если у вас отношения сложные, с низким уровнем доверия, то в начале переговоров нужно обозначить и обговорить принцип «выиграл-выиграл». Мол мы либо договоримся на условия выгодные для вас и нас или разойдемся каждый своей дорогой. Это как правило приподнимает уровень доверия и показывает заказчику что вы готовы отказаться от него.
Ну и конечно под заказчиком имеется ввиду не обязательно юр лицо, это может быть и работодатель по трудовому договору. Правда там ставки чуть иные. Например можно поспорить на что-то. Был опыт спора на половину отпуска в ту или иную сторону в зависимости от результатов проекта.
Понятие «автоматизация подхода» — слышу впервые. Было бы интересно узнать его значение и примеры реализации.
ACM — это архитектура приложения или некий набор идей для построения приложений. Для упрощения в данном вопросе будем рассматривать наше приложение из примера под названием «айсиэмочка». Чтобы отличать в тексте архитектуру от приложения на базе этой архитектуры.
ITIL — это идеология для организации процессов.
Айсиэмочку можно применить для реализации идей ITIL. Айсиэмочка не может быть лучше чем ITIL, ровно как автомобиль не может быть лучше чем методика экстремального вождения. Автомобиль лишь позволяет вам двигаться согласно данной методике или не позволяет (слишком большой, слишком сложный, не для этих дорог и т д).
Можно сказать иначе:
Айсиэмочка — это аппаратная часть (платформа) для ITIL. Есть и другие платформы, например 1С ITILIUM, IBM Tivoli, HP OV и т д
Потому тут можно говорить лишь о сравнении платформ. И я утверждаю что у Айсиэмочки как у платформы — есть преимущества, как в части методик ITIL, так и в части PMBOK и многих других.
Кракозябры они такие — в них легко запутаться :)
Давайте разложу термины по полочкам:
1. Идеологии: ITIL, PMBOK, TQM
2. Архитектуры: BPM, ACM
3. Приложения (платформы, аппаратные части): IBM Tivoli, HP OV, Айсиэмочка, 1С ИТИЛИУМ…
И это я еще бизнес процессы не тронул :) У них отдельная полочка, отличная от 3х перечисленных.
Ваш настрой мне ясен. Касательно типичной иллюстрации «вижу то, что хочу» — вы правы. Это свойство перцептивного аппарата. А знаете какое у него еще есть свойство? Это свойство называется «не вижу то что не хочу».
Таким образом то что долетает до осознания — и есть картина реального мира. Обратите внимание — не реальный мир, а лишь картина реального мира.
И вот чей перцептивный аппарат работает лучше? Ваш или мой? Чья картина мира ближе к реальности?
Наверное ваша и ваш перцептивный аппарат работает лучше моего. Вы лучше знаете факты, а мои аргументы — это просто пыль для ваших уверенных знаний.
Дак давайте ж закроем тему. Ну его к черту спор с таким глупым представителем людей, который приводит такие никчемные аргументы! Их же можно легко послать на «вижу то, что хочу» и ну и разбавить своими сверх точными знаниями из своей головы, в которой все точно и без ошибок.
Я разве утверждал обратное? Где я говорил что ITIL можно только на нашей платформе сделать?
Вот то что эффективность будет на HP OV — с чего вдруг понятно стало? И кому? На основании чего?
Мой опыт показывает что на сложных приложениях заточенных под все подряд — построить процессы сложнее. А за плечами уже 4 проекта ITSM на разных приложениях (1С, ДИРЕКТУМ ...). Видел приложения по функционалу приближенные к IBM Tivoli — в том проекте намучались, а результат был плачевный и в итоге система сдохла, перешли на 1С — со всеми вытекающими.
Так что оно может быть и понятно что эффективно после того как книжек начитаемся, а вот практика и опыт рисует чуть иные картины.
Суть претензии не понятна, т.к. она расходится с моими утверждениями. Ну или покажите где я сказал что ITIL только на нашем приложении делается и я вдруг отменил что-то из базовых понятий?
А вы задумайтесь над тем, что WP тоже понимает html+css. Вот только рынок готовых тем — это несколько иное.
Готовая тема в WP — это почти шелковый пиджак с полным климат контролем.
И я мыслю очень просто т.к. не являюсь ни программистом, ни ИТ-специалистом в местных понятиях…
Если я могу это взять и использовать — значит продукт зрелый. а если мне нужно это пилить и применять разные умные слова — значит продукт сырой.
Я за зрелые продукты.
Только и всего :)
Ну и темы — показатель для меня, который позволил мне увидеть решение и получить результат описанный в статье. Если он для вас не показатель — дело ваше.
А так да, слово «проект» тоже употребляется криво. Обычно имеется ввиду продукт. Если речь идет о неком сайте. Но словосочетание «руководитель продукта» звучит как то ляповато, а «руководитель проекта» как то лучше, вот его и употребляют :)
Как правило такая проблема возникает там где у человека мало кармы чтобы назвать себя предпринимателем, но уже как то называться хочется, потому выбирается такое мало понятное словосочетание.
Конечно это не относится к тем, кто реально рулит проектами, у которых есть срок и ограниченность во всем. Там где надо рвать когти, чтобы закрыть проект в установленный срок.
Подобающее же большинство ошибающихся, свои проекты закрывать не планируют, но один фиг называют их проектами, а себя РП :)
Я вот сейчас снова не понял что вы спросили :) и как я должен понять что речь идет о сайте с услугами? а может быть речь идет о WSDL-скрипте? Его также с полным правом можно назвать «веб-сервисом». От куда мне знать что вы сейчас сказали?
И я то ладно, у меня хватит смелости задать вопрос. А вот ее не у всех хватает. Кто то постесняется и промолчит, сделает вид что понял вас, а вы будете думать что будто бы общаетесь с человеком. Хотя на самом деле вы просто издаете звуки, а он просто на вас смотрит. Это называется «делать вид что слушаю».
И одно дело когда речь идет просто о каком то диалоге, где то в тусовке, поболтали или сделали вид что поболтали. Разбежались.
Другое дело когда речь заходит о каких-либо серьезных проектах, где людям нужно общаться, обсуждать задачи и идеи. Вот там пиши пропало. Один выпалил идею, второй сделал вид что понял, а понял все по своему, и пошло поехало… Проект тарабанит из стороны в сторону, потому что люди на разных языках говорят, хотя вроде бы одни слова произносят и пишут.
Дизайн вроде как не трогали, т.к. по большей части он там определен функционалом.
1. Адаптивная верстка действительно стала лучше. Заметно лучше.
2. В части цвета — резко. Может быть слишком. Не привычно точно. Нет возможности менять расцветку как раньше. Думаю это изменят.
Сегодня почтовый адрес стал практически заменителем паспорта из физического мира в мире Интернет.
В Google Apps с этим все хорошо. При входе на какой либо сайт я могу предъявить свою запись Google Apps, меня впустят и все будет хорошо.
Это также касается облачных информационных систем уровня предприятия.
По сути OAuth на сегодня это заменитель Active Directory, которым пользовались в старые времена :)
И тот факт что он отсутствует в Я.ПДД — печаль, катастрофа.
По этой причина я пока что сижу на Google Apps. Но с надеждой смотрю в сторону отечественного производителя :)
Никто 1С не заменяет. Просто нет смысла ее дорабатывать под различные процессы обслуживания.
Примеры:
1. Организация занимающаяся обслуживанием компрессоров в УрФО, по 4м регионам РФ. У них БП на 1С, но вот им нужно сделать систему для учета объектов обслуживания (компрессора, насосы, промышленные кондиционеры ...), сделать учет заявок и совместную работу с клиентом. Зачем им дорабатывать 1С? Финансов в этом процессе почти нет, в основном идет учет сообщений и коммуникаций между сотрудниками и клиентом. Это легко настроить на базе CasePress. Дешевле и потом нет проблем с обновлением.
2. СМИ. Выпускает журнал и свой сайт, зарабатывают на рекламе. У них 1С БП 8. CRM на чем то другом. Решили переходить на CasePress, чтобы вести все взаимодействие с клиентом в одной системе. При этом бухгалтер остался на 1С, но получает отчет в в любое время о всех сделках которые подошли к этапу выставления счета, оформляет счет и отправляет, отмечает результат. Здесь данные между системами вносятся руками. Но это не проблема для клиента. Проблемой для него было то что раньше приходилось бегать туда сюда чтобы выставить счет. Сейчас бегать не нужно, т.к. нужная информация на любом рабочем месте доступна по одному щелчку.
3. Крупная контора оказывающая проф услуги. В 20 городах РФ. Под 1000 сотрудников. Процесс «Прием сотрудника». Понятно что он регистрируется в бухгалтерии, но вот стартует он службой персонала. Точнее есть пост «Ответственный за прием». Из за размеров организации, в разных офисах, этот пост занимают разные люди. Где то сам директор филиала, где то юрист, где то офис менеджер, а где то кадровый специалист, если филиал достаточно крупный.
Тут две проблемы:
1. попробуйте ка развернуть 1с на все эти филиалы — уже беда
2. нужно делать кучу настроек, с учетом того что разные типы сотрудников могут иметь этот доступ
3. есть определенные особенности и автоматические сценарии, которые нужно как то делать. В 1С — это опять же придется делать через изменение конфигурации со всеми вытекающими проблемами с дальнейшим обновлением.
В CasePress это делается проще. Добавляется модуль (который как мы знаем живет отдельно от ядра и не влияет на обновление), пишется сценарий, добавляется пост ответственный за прием сотрудников в каждом филиале и на этот пост назначаются люди. Теперь у них появляется право приема сотрудника. Они принимают сотрудников, затем маршрут запускается и данные о сотруднике попадают во все подразделения так или иначе задействованные в приеме. В том числе в бухгалтерию, которая забивает данные в 1С для правильного оформления и регистрации в финансовой системе.
И обратите внимание — процедура очень сложная и запутанная. Ставить каждому сотруднику 1С в этом случае довольно дорого. Еще дороже их потом обучать. И это так или иначе вызывает затраты на изменение 1С — лови потом проблемы с обновлением.
А тут максимально простая система, с привычным интерфейсом, работающая с любого устройства, в т.ч. с мобильного телефона, которая легко ставится на любом рабочем месте в любом филиале, потому что является облаком. Она бесплатна.
И ее можно как угодно модифицировать без боязни за обновления, потому что каждый ее модуль не зависим от ядра. Ядро обновляется, модули продолжают работать.
> Лично я придерживаюсь такой идеи, что УПП — это все то что связано с деньгами.
В остальном — я не настаиваю на том что моя идея правильная. Хотел лишь выяснить кто и какие еще идеи использует.
Наш спор ушел в холивар ни о чем. Вы не читаете мои комментарии и начинает спорить сами с собой на тему домыслов из своей же головы.
В таком случае я ничего не смогу до вас донести. Извините.
Предлагаю закрыть тему.
Если это ЖКХ, то любая система для документооборота, например ДИРЕКТУМ.
Даже если это строительные проекты, есть специальная 1С УПП для строительства. В любом случае лучше применять что-то готовое, чем изобретать самому.
Если это крайне сложный и запущенный случай, то в любом случае я бы не рискнул править конфигурацию сложного 1С-приложения. Лучше взять что-то, что изначально заточено под такие правки. Например CasePress. Там любые настройки модуля не трогают ядро или другие модули. Обновление ядра или компонента — не затрагивает другие компоненты и может проходить автономно.
Если вы правите 1С УПП, то с выходом новой готовьтесь к пляскам с обновлением. И потратить на это как правило приходится круглую сумму или оставаться без обновления. Такова специфика финансового учета в России.
2. Бывает. Просто если взять проблему 1 и прибавить проблему 2, то произойдет перемножение проблем :) А зачем? Минус одна проблема — в разы проще реализовать проект.
4. Мегаплан как раз хорошо подходит для внедрений. Пока не идет речи о разработке. Наладить нормально процесс разработки в Мегаплане крайне сложно. Сами Мегаплановцы свою разработку ведут в другом продукте. И даже тех поддержку ведут в другом продукте.
А если мы имеем дело со сложными проектам, то управление процессами и проектами в единой среде — очень облегчает жизнь. У меня лично есть опыт создания подобной системы на базе CasePress. Приложение построено по идеологии ACM, позволяет легко адаптироваться под любые бизнес процессы любой сложности и взаимоувязывать их.
При этом если у меня встанет вопрос с финансовым учетом или зарплатой — я лучше возьму 1С, но постараюсь ее не изменять :) Или изменять но как то по минимуму.
Лично я придерживаюсь такой идеи, что УПП — это все то что связано с деньгами. Какие то обслуживающие бизнес-процессы стараюсь в нее не пихать. Для этого есть более удобные приложения, которые легко интегрировать с БП, КА или УПП. Без внесения изменений в конфигурацию 1С.
2. Я располагаю статистикой, т.к. есть большой опыт работы как на предприятиях, так и в консалтинге, где пришлось повстречаться с убитыми проектами внедрения. Печальное зрелище.
3. Объем работы не маленький — это следствие ошибочных решений. У меня есть опыт внедрения 1С КА 8, за 3 месяца почти в одного, там где до меня целая бригада программистов трудилась более года и не смогли довести проект до результата.
4. Ссылочки имелись ввиду на решения по управлению такими проектами, а не 1С-приложения. С ними хорошо знаком :)
Но 1С УПП — это относительно зрелый продукт. А преимущество зрелых продуктов в том что их можно внедрять без доработки. Да, это будет не так «удобно», с точки зрения пользователя. Но зато меньше рисков. Рисков, когда проект вылетает за все мыслимые бюджет и сроки.
Думаю мы не будем спорить о том что большая часть проектов внедрения 1С УПП провальны? + затягиваются на годы.
Для себя выработал вот такие правила. Поделился точкой зрения.
Если есть другие решения — ссылочку пожалуйста. С удовольствием почитаю.
У нас одним из камней является важность версионирования.
Текущая система хранения документов позволяет создавать версии, но не позволяет править файлы прямо на сервере. Приходится скачивать, а потом закачивать обратно. Это проблема.
Наслышаны о WebDAV и его возможности работать с версиями, но в Яндекс.Диске эта возможность отсутствует. Было бы интересно раскрыть эту часть. Планировали? Решали? Разбирали?
2. Где то к обеду получил 2хСчастья за счет того что открыл для себя feedly.com
3. Вообще удивился, как раньше его не замечал?
Какой там Google Reader? Давай досвидания!
Алгоритм примерно такой: пробуем поставить и описать задачу. Рационалам — это просто. Иррационалы — начнут буксовать.
1. Если видим рациональный подход — работаем стандартно по ТЗ, сроку и бюджету.
2. Если видим иррациональный подход, меняем схему:
2.1. поддерживаем заказчика в части идеи «тут все не продумать, четкое ТЗ описать сложно, нужно будет над этим много поработать» — это их стиль, ничего не попишешь.
2.2. но обосновываем спецификой такого подхода, предлагаем оплату по периодам (неделя, месяц ...) исходя из прогноза частоты встречь
2.3. плюс обозначаем бонус по завершению
Суть:
п.2.3. — должен защитить заказчика от пробуксовок со стороны исполнителя (бонус хочется) и мотивирует сторону исполнителя на закрытие (чем быстрее закончим тем быстрее получим бонус)
п.2.2. — защищает затраты исполнителя и при этом мотивирует заказчика на завершения (каждая итерация увеличивает его затраты)
При этом обе стороны могут работать в максимально надежных условиях, с мотивацией и защитой.
Иррационалов как правило такой подход устраивает, т.к. они сами не очень то любят работать в сроках и рамках. Такова их природа. Потому они чаще на это идут чем рационалы.
Да, если у вас отношения сложные, с низким уровнем доверия, то в начале переговоров нужно обозначить и обговорить принцип «выиграл-выиграл». Мол мы либо договоримся на условия выгодные для вас и нас или разойдемся каждый своей дорогой. Это как правило приподнимает уровень доверия и показывает заказчику что вы готовы отказаться от него.
Ну и конечно под заказчиком имеется ввиду не обязательно юр лицо, это может быть и работодатель по трудовому договору. Правда там ставки чуть иные. Например можно поспорить на что-то. Был опыт спора на половину отпуска в ту или иную сторону в зависимости от результатов проекта.
ACM — это архитектура приложения или некий набор идей для построения приложений. Для упрощения в данном вопросе будем рассматривать наше приложение из примера под названием «айсиэмочка». Чтобы отличать в тексте архитектуру от приложения на базе этой архитектуры.
ITIL — это идеология для организации процессов.
Айсиэмочку можно применить для реализации идей ITIL. Айсиэмочка не может быть лучше чем ITIL, ровно как автомобиль не может быть лучше чем методика экстремального вождения. Автомобиль лишь позволяет вам двигаться согласно данной методике или не позволяет (слишком большой, слишком сложный, не для этих дорог и т д).
Можно сказать иначе:
Айсиэмочка — это аппаратная часть (платформа) для ITIL. Есть и другие платформы, например 1С ITILIUM, IBM Tivoli, HP OV и т д
Потому тут можно говорить лишь о сравнении платформ. И я утверждаю что у Айсиэмочки как у платформы — есть преимущества, как в части методик ITIL, так и в части PMBOK и многих других.
Кракозябры они такие — в них легко запутаться :)
Давайте разложу термины по полочкам:
1. Идеологии: ITIL, PMBOK, TQM
2. Архитектуры: BPM, ACM
3. Приложения (платформы, аппаратные части): IBM Tivoli, HP OV, Айсиэмочка, 1С ИТИЛИУМ…
И это я еще бизнес процессы не тронул :) У них отдельная полочка, отличная от 3х перечисленных.
Таким образом то что долетает до осознания — и есть картина реального мира. Обратите внимание — не реальный мир, а лишь картина реального мира.
И вот чей перцептивный аппарат работает лучше? Ваш или мой? Чья картина мира ближе к реальности?
Наверное ваша и ваш перцептивный аппарат работает лучше моего. Вы лучше знаете факты, а мои аргументы — это просто пыль для ваших уверенных знаний.
Дак давайте ж закроем тему. Ну его к черту спор с таким глупым представителем людей, который приводит такие никчемные аргументы! Их же можно легко послать на «вижу то, что хочу» и ну и разбавить своими сверх точными знаниями из своей головы, в которой все точно и без ошибок.
Вот то что эффективность будет на HP OV — с чего вдруг понятно стало? И кому? На основании чего?
Мой опыт показывает что на сложных приложениях заточенных под все подряд — построить процессы сложнее. А за плечами уже 4 проекта ITSM на разных приложениях (1С, ДИРЕКТУМ ...). Видел приложения по функционалу приближенные к IBM Tivoli — в том проекте намучались, а результат был плачевный и в итоге система сдохла, перешли на 1С — со всеми вытекающими.
Так что оно может быть и понятно что эффективно после того как книжек начитаемся, а вот практика и опыт рисует чуть иные картины.
Суть претензии не понятна, т.к. она расходится с моими утверждениями. Ну или покажите где я сказал что ITIL только на нашем приложении делается и я вдруг отменил что-то из базовых понятий?
Готовая тема в WP — это почти шелковый пиджак с полным климат контролем.
И я мыслю очень просто т.к. не являюсь ни программистом, ни ИТ-специалистом в местных понятиях…
Если я могу это взять и использовать — значит продукт зрелый. а если мне нужно это пилить и применять разные умные слова — значит продукт сырой.
Я за зрелые продукты.
Только и всего :)
Ну и темы — показатель для меня, который позволил мне увидеть решение и получить результат описанный в статье. Если он для вас не показатель — дело ваше.