Комментарии 8
Всё это хорошо только до тех пор, пока не начинается бюрократия. Потому что приходят люди и говорят примерно следующее:
«А теперь мы должны скрыть группу людей, потому что они слишком секретные. И ими должен управлять отдельный администратор.»
Или «А теперь делаем группу людей, которые ходят в отпуска по особому графику».
«А теперь мы должны скрыть группу людей, потому что они слишком секретные. И ими должен управлять отдельный администратор.»
Или «А теперь делаем группу людей, которые ходят в отпуска по особому графику».
У вас кастомные формы и внешняя база, зачем вам SharePoint?
Я вот делал заявки на отпуск, сделал тупо список с полями и стандартный процесс согласования. Причем работает он на сайте отдела, никаких дополнительных разграничений доступа не надо. Люди из другого отдела и не увидят, если им явно доступ не дать. (это к первому комменту).
Дальше список сохраняется как шаблон и размножается на N отделов, каждому настраивается свой процесс за 5 минут.
Дальше если понадобится куда-то интегрировать, то я возьму SSIS, который умеет переливать данные. А для дополнительных проверок тупо напишу event receiver или сделаю логику в workflow.
ИМХО именно так надо делать решения на шарике, а не струячить код, формы и прочие интеграции.
Я вот делал заявки на отпуск, сделал тупо список с полями и стандартный процесс согласования. Причем работает он на сайте отдела, никаких дополнительных разграничений доступа не надо. Люди из другого отдела и не увидят, если им явно доступ не дать. (это к первому комменту).
Дальше список сохраняется как шаблон и размножается на N отделов, каждому настраивается свой процесс за 5 минут.
Дальше если понадобится куда-то интегрировать, то я возьму SSIS, который умеет переливать данные. А для дополнительных проверок тупо напишу event receiver или сделаю логику в workflow.
ИМХО именно так надо делать решения на шарике, а не струячить код, формы и прочие интеграции.
Спасибо Вам огромное за интерес к нашему посту, действительно, способов реализации функциональности существует много, предложенный Вами считаем рабочим — особенно, если необходимо быстро сделать и обкатать бизнес-процесс в жизни.
Есть НО:
— пользовательский интерфейс должен выглядеть просто и понятно, так, чтобы люди без особой подготовки могли с ним работать. с помощью кастомных форм мы решали именно задачу. Как Вы сами знаете, со стандартным UI SharePoint это не всегда просто
— у нас есть блок управления различными заявками, отпуска, переговорки и т.д… в этом и была суть всего решения — все нужно под рукой
— про права мы не стали писать. они есть, а реализованы примерно вот так — habrahabr.ru/company/eastbanctech/blog/211735/
В случае тиражирования одного и того же решения возникают вопросы, например, SSIS будет тоже тиражироваться для всех отделов, т.е. если 100, то будет 100 пакетов, и их придется администрировать, а что делать с обновлениями, когда оно настроено для каждого — опять руками для всех?
Как видите всегда есть свои за и против :) для нас в данном случае важным были простота и понятность UI в корпоративном стиле и снижение затрат на поддержку и обновления.
Есть НО:
— пользовательский интерфейс должен выглядеть просто и понятно, так, чтобы люди без особой подготовки могли с ним работать. с помощью кастомных форм мы решали именно задачу. Как Вы сами знаете, со стандартным UI SharePoint это не всегда просто
— у нас есть блок управления различными заявками, отпуска, переговорки и т.д… в этом и была суть всего решения — все нужно под рукой
— про права мы не стали писать. они есть, а реализованы примерно вот так — habrahabr.ru/company/eastbanctech/blog/211735/
В случае тиражирования одного и того же решения возникают вопросы, например, SSIS будет тоже тиражироваться для всех отделов, т.е. если 100, то будет 100 пакетов, и их придется администрировать, а что делать с обновлениями, когда оно настроено для каждого — опять руками для всех?
Как видите всегда есть свои за и против :) для нас в данном случае важным были простота и понятность UI в корпоративном стиле и снижение затрат на поддержку и обновления.
Эти НО обычно выдумываю разработчики.
У вас получается аж два интерфейса — основной интерфейс сайта, как на графике, и кастомная форма, которая похожа на стандартный интерфейс SharePoint 2010, но значительно переделана. Самый лучший интерфейс — стандартный. Просто потому что он везде одинаковый и везде описан. Пользователю достаточно один раз научиться работать со стандартным интерфейсом и он сможет им пользоваться везде, независимо от того, что вы внутри напрограммируете.
Кастом нужен в двух случаях — а) создать вау-эффект, это 1-2 страницы портала, б) оптимизировать под конкретный сценарий, например отметка на карте вместо ввода координат в форме. В остальных случаях лучше стандартный, особенно с точки зрения экономической эффективности.
То что блок для многочего вообще не является оправданием. Отпусками пользуются люди 2-3 раза в год в среднем. Переговорками от 2-3 раз в месяц. То есть минимум в 12 раз чаще (!). Кроме этого переговорки обычно бронируют из exchange, у него кстати есть web access, так что веб интерфейс на шарике не сильно нужен.
Что по поводу SSIS, то проблем никаких нет сделать тупо цикл внутри пакета, который будет бежать по всем спискам отпусков. А на корневом узле сделать скрытый список списков или доставать их поиском. Так что нет необходимости поддерживать более одного пакета.
ИМХО ваше решение, как и подавляющее большинство других, не оптимально с точки зрения экономики, при использовании SharePoint. Кстати, что, из того что вы сделали, требует именно SharePoint?
У вас получается аж два интерфейса — основной интерфейс сайта, как на графике, и кастомная форма, которая похожа на стандартный интерфейс SharePoint 2010, но значительно переделана. Самый лучший интерфейс — стандартный. Просто потому что он везде одинаковый и везде описан. Пользователю достаточно один раз научиться работать со стандартным интерфейсом и он сможет им пользоваться везде, независимо от того, что вы внутри напрограммируете.
Кастом нужен в двух случаях — а) создать вау-эффект, это 1-2 страницы портала, б) оптимизировать под конкретный сценарий, например отметка на карте вместо ввода координат в форме. В остальных случаях лучше стандартный, особенно с точки зрения экономической эффективности.
То что блок для многочего вообще не является оправданием. Отпусками пользуются люди 2-3 раза в год в среднем. Переговорками от 2-3 раз в месяц. То есть минимум в 12 раз чаще (!). Кроме этого переговорки обычно бронируют из exchange, у него кстати есть web access, так что веб интерфейс на шарике не сильно нужен.
Что по поводу SSIS, то проблем никаких нет сделать тупо цикл внутри пакета, который будет бежать по всем спискам отпусков. А на корневом узле сделать скрытый список списков или доставать их поиском. Так что нет необходимости поддерживать более одного пакета.
ИМХО ваше решение, как и подавляющее большинство других, не оптимально с точки зрения экономики, при использовании SharePoint. Кстати, что, из того что вы сделали, требует именно SharePoint?
Вот тут мы видимо уже переходим в плоскость философии и различных точек зрения на корпоративные порталы, обсуждать можно долго и приводить доводы на контордоводы, все же позволим себе прокомментировать:
1. С точки зрения внутреннего маркетинга, портал — это не только инструмент, а еще и способ создать красиво и донести до сотрудников информацию о корпоративной культуре, новостях и т.д. И тут важно, чтобы не 1 — 2 странички были «Вау», а все, и скорее удобны, просты и дружелюбны, а также соответствовали корпоративному брендбуку.
2. Научить можно кого угодно и чему угодно :) Только люди в компании меняются (особенно актуально для больших организаций). Просто, удобно и дружелюбно — значит не нужно учить каждый раз заново.
3. Каждая из описанных функций используется не очень часто, действительно, Вы правы. А есть еще архив документов, документооборот, новостные ленты и т.д., и если каждый из этих инструментов будет не очень удобный, то на вопрос времени посмотрим уже по-другому.
4. Про Exchange: мы не подменяли стандартную функциональность, а лишь ее расширили. Например, информацией об оборудовании в конференцзалах, это важно, когда для разных встреч нужны переговорки разной вместимости и укомплектованности — опять просто, удобно…
5. SSIS, который делает цикл по всем спискам, и скрытый список — и каждый раз при развертывании этого решения на новый узел, нужно подправить этот SSIS :) Технически решение понятно, но опять — не дружелюбно это.
6. Конечно какие-то вещи можно сделать и без портала, но в целом портал — это стратегический выбор, который позволяет решать на единой платформе много разных задач и реализовать документооборот (в статье про миграцию есть те части портала, которые без него реализовать дороже, чем с ним).
В нашем решение — простота, удобство, дружелюбность стоят во главу угла, и, наверное, есть ситуации, когда это важнее. Вот тут как раз и можно обсудить те ситуации, когда портал это простой стандартный инструмент, а когда нужно его брендировать и делать кастомным — все зависит от решаемых задач и целей.
Иногда ощущение сотрудника, что что-то сделали для него, чтобы ему было хорошо и удобно, дороже. Особенно для компаний, в которых человеческий капитал — это главное.
1. С точки зрения внутреннего маркетинга, портал — это не только инструмент, а еще и способ создать красиво и донести до сотрудников информацию о корпоративной культуре, новостях и т.д. И тут важно, чтобы не 1 — 2 странички были «Вау», а все, и скорее удобны, просты и дружелюбны, а также соответствовали корпоративному брендбуку.
2. Научить можно кого угодно и чему угодно :) Только люди в компании меняются (особенно актуально для больших организаций). Просто, удобно и дружелюбно — значит не нужно учить каждый раз заново.
3. Каждая из описанных функций используется не очень часто, действительно, Вы правы. А есть еще архив документов, документооборот, новостные ленты и т.д., и если каждый из этих инструментов будет не очень удобный, то на вопрос времени посмотрим уже по-другому.
4. Про Exchange: мы не подменяли стандартную функциональность, а лишь ее расширили. Например, информацией об оборудовании в конференцзалах, это важно, когда для разных встреч нужны переговорки разной вместимости и укомплектованности — опять просто, удобно…
5. SSIS, который делает цикл по всем спискам, и скрытый список — и каждый раз при развертывании этого решения на новый узел, нужно подправить этот SSIS :) Технически решение понятно, но опять — не дружелюбно это.
6. Конечно какие-то вещи можно сделать и без портала, но в целом портал — это стратегический выбор, который позволяет решать на единой платформе много разных задач и реализовать документооборот (в статье про миграцию есть те части портала, которые без него реализовать дороже, чем с ним).
В нашем решение — простота, удобство, дружелюбность стоят во главу угла, и, наверное, есть ситуации, когда это важнее. Вот тут как раз и можно обсудить те ситуации, когда портал это простой стандартный инструмент, а когда нужно его брендировать и делать кастомным — все зависит от решаемых задач и целей.
Иногда ощущение сотрудника, что что-то сделали для него, чтобы ему было хорошо и удобно, дороже. Особенно для компаний, в которых человеческий капитал — это главное.
От того что вы 6 раз повторите «удобный» в разных формах, портал удобнее не станет. Я не глупый заказчик, на меня это не действует.
«Красиво донести информацию» и «удобно работать» — разные вещи. Самые красивые порталы, которые я видел, были предельно непрактичны. Реальная работа велась на обычных сайтах, созданных для подразделений. По факту в 99,9% порталов удобство и красота понятия противоположные.
Учить все равно надо, потому что обучение это не только приобретение знаний, но и мотивация. Причем стандартному функционалу учить легче, ибо он везде одинаковый, даже в других компаниях. Можно использовать существующие материалы. Нестандартный интерфейс сам по себе является не преимуществом, а недостатком с точки зрения экономики.
Теперь конкретнее.
Вот вы перечислили задачи: отпуски, бронирование переговорных, документооборот.
Если надо человеку отпуск оформить, то он все равно пойдет и нажмет нужные кнопки, даже если будет стандартный интерфейс. Или надо ему переговорку забронировать, тоже сделает то что нужно. Если вы закрываете потребности людей, то они будут пользоваться тем, что вы сделали, несмотря на красоту, «дружелюбность» и «удобство». Тоже самое касается документооборота и других практических вещей. А вот если не пользуются, то два варианта — не знают или действительно не удобно. И если действительно не удобно, то это нельзя исправить просто добавлением красивостей в интерфейс.
Новостные ленты и прочая муть не нужна почти никому, кроме тех, кто за эти новости отвечает.
Чтобы у сотрудника было ощущение что сделали что-то для него, то нужна персонализация, которая вообще никаким боком не относится к «удобству».
«Красиво донести информацию» и «удобно работать» — разные вещи. Самые красивые порталы, которые я видел, были предельно непрактичны. Реальная работа велась на обычных сайтах, созданных для подразделений. По факту в 99,9% порталов удобство и красота понятия противоположные.
Учить все равно надо, потому что обучение это не только приобретение знаний, но и мотивация. Причем стандартному функционалу учить легче, ибо он везде одинаковый, даже в других компаниях. Можно использовать существующие материалы. Нестандартный интерфейс сам по себе является не преимуществом, а недостатком с точки зрения экономики.
Теперь конкретнее.
Вот вы перечислили задачи: отпуски, бронирование переговорных, документооборот.
Если надо человеку отпуск оформить, то он все равно пойдет и нажмет нужные кнопки, даже если будет стандартный интерфейс. Или надо ему переговорку забронировать, тоже сделает то что нужно. Если вы закрываете потребности людей, то они будут пользоваться тем, что вы сделали, несмотря на красоту, «дружелюбность» и «удобство». Тоже самое касается документооборота и других практических вещей. А вот если не пользуются, то два варианта — не знают или действительно не удобно. И если действительно не удобно, то это нельзя исправить просто добавлением красивостей в интерфейс.
Новостные ленты и прочая муть не нужна почти никому, кроме тех, кто за эти новости отвечает.
Чтобы у сотрудника было ощущение что сделали что-то для него, то нужна персонализация, которая вообще никаким боком не относится к «удобству».
У вас кастомные формы и внешняя база
В статье указано, что для хранения заявок, истории заявок, фактических и планируемых отпусков используются списки SharePoint. Где вы прочитали про внешнюю базу? У нас такой базы нет, если не считать контентовую базу самого шарика :).
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сервис управления заявками на отпуска для SharePoint 2013 в интеграции с БОСС-Кадровик