Вот cобрались серьезные дяди за круглым столом еще более круглой компании и решили внедрить у себя Систему Электронного Документооборота на базе MS Sharepoint 2013. На что должны дяди обратить внимание в первую очередь при трате своих, законным путем нажитых, денег.
«Вы песен хотите? Их есть у меня!».
Оставим в покое сравнительные характеристики и рекламные слоганы о том какой Электронный документооборот лучше — об этом не писал только ленивый. А уж сколько статей на эту тему наваяно — и не сосчитать, но вот несколько самых важных ключевых моментов — особо так и не рассмотрено. Обойдены они почему то пристальным внимание работников чернилов и пера. Предлагаю немножко ознакомиться с этим тайными ритуалами и все-таки посвятить пару незамысловатых строк проблеме выбора.
Итак давайте разберемся чего вообще мы хотим от всей это музыки. Нам требуется удобоваримый, удобофункциональный, достаточно шустрый продукт на платформе MS Sharepoint 2013, который можно развивать в дальнейшем и с достаточно адекватными затратами как на первоначальное внедрение так и на дальнейшее сопровождение.
1. Четкое понимание задач которые необходимо решить, притом не ждать когда вам «расскажут» что вам впаривают, а постараться самим представить общую картину по своим требованиям.
Для начала нужно понимать пару важных вещей:
a) Разработка СЭД с нуля и своими силами — это нереальное зло. Если же вы все таки решили «разработать» это сами — то над вами будут смеяться даже гномы в лесу. Забудьте.
b) Систем электронного документооборота под MS Sharepoint 2013 в России — буквально по пальцам пересчитать и все это готовые коробочные решения разной степени кастомизации. Они отличаются в мелочах и во вторичном функционале — но базовую составляющую классического документооборота выполняют на 100% — независимо от их навороченности и замысловатости.
Электронный документооборот — это по сути движение и хранение непослушных документов внутри ВАШЕЙ компании. Очень четко определите для себя что именно ВЫ хотите — как например: регистрацию входящих / исходящих, договорной документооборот, какие статические бизнес процессы, возможности маршрутизации, ЭЦП, задачи и поручения, и т.д. Что конкретно для ВАС важно вне зависимости от решения? Не то что предлагает разработчик за конкретные деньги (но об этом позже), а то что первично требуется вам и только ВАМ. И не в смысле — из задач, выполняемых конкретным рассматриваемым в данный момент продуктом, а в смысле именно ВАШИХ потребностей и хотелок.
Конечно при первичном разговоре, заказчик первым делом на вопрос «что именно вам требуется от нашего горячолюбимого СЭД» — бодро и не моргнув глазом отвечает: «Всё!» — но что конкретно, уточнить затрудняется, кроме самых общих понятий «Регистрация документов и согласование договоров». Точно так же как и разработчик, на вопрос «Что позволяет делать ваше решение?» — энергично рапортует «Всё!».
В данном случае, оба заинтересованных лица по разные стороны баррикад, по сути — выдают желаемое за действительное, но друг друга абсолютно не понимая, при этом одно лицо крайне срочно желает расстаться с корпоративными деньгами, а другое, не менее корпоративное лицо — их желает срочно принять. И совершенно неважно что на переговорах сидят серьезные дядьки в дорогущих галстуках и запонках по цене среднего необитаемого острова в очень тихом океане.
Это происходит именно потому что — частенько, изначально ответственный у заказчика — не заморачивается с четким определением требуемых для решения задач, а рассматривает весь проект в широком разрезе, естественно отождествляя свое сэкономленное время со временем компании и так же естественно, горя желанием, потратить его как можно меньше на данные исследования, а зарплату и пряников получить как можно больше. А вот зря! Его пряники — очень тесно взаимосвязаны с пряниками Генерального директора, у которого они всегда больше и крепче чем у лица ответственного за проект. И в случае неудачи — Генеральный директор или Владелец компании будет крайне конкретен и максимально детализирован в своей речи — которая будет изобиловать нарицательными и нелитературными эпитетами по отношению к ответственным за проект лицам, а так же к их близким и дальним родственникам. Берегите пряники.
В общем перед тем как залезть в поисковик и начать выбирать коробочное решение и разработчика — постарайтесь как можно более педантично понять что именно хочет получить ваша компания на выхлопе (а вы ее представитель), притом конкретики желательно побольше, а общих фраз поменьше.
2. Обязательное понимание — требуемого вам базового функционала от коробочного решения, опять же — именно в соответствии с вашими требованиями, а не с натяжкой за уши того что вам предлагают.
Категорически необходимо дотошно понять в конкретном рассматриваемом решении — что вы видите в его функционале, так сказать в самом — цимусе. То есть обязательно должно быть понятно что основные требования к функционалу Любого электронного документооборота на Sharepoint это:
— дружелюбные карточки с функциональной частью по документам, процессам и задачам, плюс конечно поиск
— далее конечно удобство управления бизнес процессами и их маршрутизации
— удобное расположение библиотек и навигация по разделам и фильтрация
— максимально позитивное отображение таблиц по спискам документов
— ролевое участие сотрудников
— возможности делегирования и замещения
— а так же понятное создание собственных списков и связь полей карточек- удобная админка, и адекватный интерфейс
— комментарии, листы визирования и маршрутизации, отчеты
— нормальная техподдержка, которая в предновогодний вечер всегда готова отложить праздничного гуся в сторону, выйти из-за стола и пойти за компьютер, с видимым удовольствием решать проблемы заказчика. Ну или что бы технику в поддержку всегда можно было позвонить в любое время и просто с ним потрепаться о том о сём. Они это любят.
Само собой это в минимуме, и этих пунктов может быть великое множество, я всего лишь перечислил основополагающие — то есть как у машины может быть нюансов много, но кузов колеса и двигатель должны быть стопроцентно. Но это самые основные вещи — которые обязательно должны присутствовать, если они есть — имеет смысл продолжать разговор, если же что то не вяжется — забудьте и не вспоминайте. (про цену и переговоры в следующем пункте)
Не нужно пытаться сразу объять необъятное и пытаться за уши притянуть все понимание функционала сложных решений на базе MS Sharepoint 2013 или считать себя мега-гуру в СЭД, засыпая вопросами по бумажке стыренной из инета — ни в чем не повинного менеджера или мчаться в магазин за тысячестраничным руководством администратора, достаточно просто здраво понимать основы требуемых вам функций от рассматриваемого решения и отталкиваться от них.
Это то — что максимально необходимо и должно присутствовать фактически незыблимо и в единственно правильной вариации. Все остальное — это уже частности и больше зависят от конкретных требований заказчика, требований отдельных лиц, отделов компании или просто дополнительного функционала, который не является необходимым — но зато крайне приятен (конечно зависит от самого дополнительного функционала) — с этим на Sharepoint держим ухо востро (в этом есть пара подводных камней) — поскольку помним что бесплатный сыр бывает только в последнем пристанище диких мышек.
3. Детальное осознание на ментальном уровне — за что конкретно из существующего функционала вы платите добровольно, а что не является для вас важным, но вам впаривают как мега-нужные фишки — поскольку любой чих заранее учтен в конечной цене.
Давайте снова вспомним — что нам конкретно требуется, как было указано в самом начале: это удобоваримый, удобофункциональный, достаточно шустрый продукт на платформе MS Sharepoint 2013, который можно развивать в дальнейшем и с достаточно адекватными затратами как на первоначальное внедрение так и на дальнейшее сопровождение. Запомним каждое слово из этого предложения. Чуть ниже — подробное разделение на некоторые пункты:
Платформа.
Никаких MS Sharepoint 2010. Это устаревшая система, но цена 2010 го не отличается от цены за 2013, поэтому никакие оправдания разработчика почему система реализовывается на предыдущей версии — не катят. При покупке вами лицензий и внедрении продукта — версия Sharepoint может быть только самой последней, и никаких отговорок. Если разработчику нечего показать из 2013 го Sharepoint на демке — то и говорить не о чем. Так же как и не о чем говорить с потенциальным подрядчиком — в случае если по любым причинам, он отказывается показать демо-версию продукта по следующим причинам: «кое что обновляют», «переносят сервер», «заболел менеджер», «на планету произошло нашествие людей-помидоров» и т.д.
Если компания позиционирует в своем активе коробочное готовое решение на Sharepoint 2013 — то демо стенд в круглосуточном доступе должен быть в наличии всегда — в режиме «вынь да положь». Не 2007, не 2010 — а именно 2013 шарик. Любые отмазки под каким либо предлогом от показа демки (независимо от размера компании) — разговор в пользу бедных. Могут конечно у вас попросить дополнительные данные (ФИО, название компании которую вы представляете, и корпоративную почту) — но это нюансы, конечно вы должны быть к ним готовы, если и вы позиционируете себя как серьезный заказчик — а не просто так «по магазину пошляться», никто не будет облизывать клиента который пишет с vasiapupkin@ofigennayapochta.ru
В общем правило первое — вы платите только за последнюю версию, и любые отмазки почему вам будут внедрять устаревший продукт — не катят. Нет демки последней версии Sharepoint — разговор закрыт.
Функциональные элементы.
Sharepoint — это, как уже упоминалось, конструктор. И когда разработчик показывает вам свою версию СЭД отдельно или в связке с Корпоративным порталом — это именно его видение мироустройства — «художник так видит». Конечно нюансы могут не совпадать с вашим мировоззрением, но достаточно капли воды что бы догадаться о существовании океана. Поэтому если вы лицезрели достаточно адекватно сделанный продукт, то поверьте, разработчику совершенно не составит труда «допилить» его под ваши нужды или исправить что то в соответствии с вашими пожеланиями — это нормально и это правильно. На данной платформе можно реализовать практически все что только душа пожелает.
Другой вопрос что некоторые вещи — выдаются за собственную разработку — но на самом деле присутствуют по умолчанию в стандартном функционале Sharepoint. К примеру — совместное редактирование документа.
Существует совершенно замечательное (бесплатное) приложение от Microsoft — WebApps Server. Оно позволяет совершенно фееричные вещи выполнять в режиме совместной работы с документом. То есть данная вещь уже реализована и прекрасно себя чувствует — качайте — связывайте с шариком и наслаждайтесь. Но как выясняется разработчик — сделал подобный функционал в составе своего решения — то есть 'придумал велосипед" сам.
Зачем? То есть спору нет — функционал хороший если идет по умолчанию — когда даже не требуется делать каких либо телодвижений что бы он работал, но это в конечно цене будет все равно обязательно учтено. Нужен он вам в составе продукта или нет — вы все равно заплатите, поскольку в разработку данного функционала — были вложены деньги и время, хотя на практике можно сэкономить не малые средства (или к примеру учесть свой финансовый интерес, ну а как же без него то) — если к примеру взять продукт который дешевле, а после этого уже своими силами (что не сложно) — прикрутить WebApps. Ну это как вариация конечно. Или к примеру My Site (личный кабинет) — входит в состав Enterprise, зачем городить огород и придумывать свой кабинет, когда совершенно спокойно можно сделать его на базе уже готового и мало того, входящего в стандартный состав Sharepoint.
Очень серьезные объяснения — что это жизненно необходимо, берутся за такую фишку как управление статусами выполнения задач через надстройку Outlook (фишка для руководства). Предварительно, вещь шикарная — и привлекает первоначальное внимание колоссально. «Это хочу. Дайте два!!». На деле если это рассмотреть — то все более прозаично. Де факто, в нашу эпоху «модернизации» — руководство любой компании поголовно сидит на планшетах, на которых Outlook используется крайне вяло. То есть это Android и iOS — и соответственно эта надстройка нужна кому угодно, но только не руководству, то есть что бы ее использовать требуется Windows и как следствие пребывание пользователя перед стационарной машиной или ноутбуком, что опять же исключает мобильность и привлекательность такой фишки. Стоит ли за нее платить в составе решения- к примеру лишних 2-3 тыс зеленых абрикосов — не знаю. На ваше усмотрение, учитывая что потребуется ее поддержка и обновление и т д. и т п. + опять же привязка к одному конкретному разработчику.
И вот таких вещей — который выдаются за мега-супер функуционал — достаточно много если пристально покопаться. Нет, конечно понятно что даже просто грамотная настройка и установка стандартного шарика — стоит определенных средств, но она не может в рамках одной средневзятой компании исчисляться несколькими сотнями тысяч.
Правило второе — обязательно проверьте по Функциональной таблице — что уже внесено в Sharepoint 2013 самим Microsoft, а где разработчик налепил своих «велосипедов» для удорожания своего корбочного решения. Очень часто бывает — что заявленный уникальный функционал — уже присутствует в самом стандартном шарике в том или ином виде, а разница в цене составляет несколько сотен тысяч за минимальные изменения интерфейса. Если вы будете понимать — от каких пунктов можно отказаться, поскольку будете знать что они уже есть в продукте изначально, вы сможете выбрать решение которое будет менее финансово затратно.
Дизайн
Дизайн может быть хорошим или плохим. Это не важно — хороший внешний вид легко достигается путем. В любом случае вам всегда понадобится брендирование в вашем корпоративном стиле или как минимум просто применение корпоративных цветов и логотипа. Конечно кто то захочет авторский дизайн и тогда нужно быть готовым к закладке определенного финансирования этого вопроса. Но самый лучший вариант это не заморачиваться. а просто разместить свой логотип и изменить стилистику цветности и шрифтов и размещаемых картинок. В документообороте — просто должен быть понятный интерфейс, а в портале — просто приятный и корпоративный стиль. Совершенно замечательных красот можно добиться путем простого премодерирования фоток сотрудников и картинок в контенте. Поверьте — самый требовательное руководство останется довольное внешним видом — без особых затрат, в конце концов — это инструмент и не новогодняя елка.
Если же вы решили разработать и применить уникальный дизайн, да еще и со скриптовыми элементами — будьте готовы к довольно серьезным первоначальным затратам (только разрисовка дизайн макетов и интерфейса — съест минимум 3-4 тыс. зеленых марципанов и плюс еще конечно его применение — что еще сверху от 10 тыс.) — мало того, в будущем вам придется все дополнительные нафантазируемые модули и разделы — отрисовывать и применять в этом же дизайне и стиле, а это снова деньги. В общем дело хорошее — но бюджета требует очень особого. Дизайн должен быть приятным и не более (цвета не важны — их можно всегда быстро изменить), хорошо если он есть приличный в продукте, но если цена без серьезной отрисовки модулей и общего вида, достаточно вкусная, то путем некоторых манипуляций своими силами — у вас будет брендированнный приятный продукт — без серьезных переплат за мега-дизайн включенный в конечную стоимость.
Кастомизация Sharepoint 2013. Самый хитрый пункт. Самый самый. И чуть ли не самый важный.
По сути — заказчик очень любит глубокую кастомизацию. Притом чем глубже — тем оно богаче выглядит. Вариантов, в общем масштабе, существует два. Кастомизация стандартного функционала и инструментов — приведение их удобоваримому виду и функционалу с аккуратными вкраплениями стороннего кода, с максимальным упором на выполнение требуемых задач, но за основу берется именно функционал Sharepoint. И второй — это применение разработчиком своих функциональных вещей и большое количество собственного кода т.е. решение «в себе». То бишь — в одном случае мы берем — приготовленные для нас стройматериалы и строим дом, в другом случае мы заменяем все или часть приготовленных стройматериалов на свои — и тоже строим дом. Результат и в том и другом случае примерно одинаков — сотворить удобное и надежное жилище. В принципе и то и другое — очень хорошо и правильно для всех — кроме конечно заказчика.
Вот тут есть определенный момент. При покупке коробочного решения, в котором разработчиком была применена сильная кастомизация по своим внутренним стандартам, заказчик берет на себя серьезный риск — в дальнейшем не иметь возможности править своими силами часть или часто почти все функциональные модули или логику системы предложенной разработчиком коробочного решения. И при любом поползновении на «допилку» или внесение каких то правок «под себя» — сталкивается с невозможностью вообще сделать что либо — кроме того что заложено в админку. А Панель Администрирования — какая бы гибкая не была — никогда не сможет учесть всех требований к правкам заказчика в будущем. Дальнейший сценарий — всегда одинаков, заказчик в дальнейшем вынужден за каждой мелочью (кроме наполнения контентом) — обращаться к разработчику и видеть совершенно потрясающие по размеру своей наглости счета на доработки. Это нормально. Поэтому обязательно, если в приоретаемом продукте предполагаются сильно закастомизированная логика взаимодествия модулей или частей, необходимо сразу обусловливать в договоре предварительные цены на дальнейшие доработки. Иначе вам ставят коробочное решение (конечно без предоставления исходников — поскольку они на вес золота) — и после этого потребуется еще бюджет на доработки в несколько раз легко превосходящий стоимость самого коробочного решения.
Для примера можно допустим рассмотреть такой момент: в стандартном функционале шарика — нет карточки документа. Ну вот нет и все. Конечно в СЭД, она является краеугольным камнем сервиса определения принадлежностей документа и вообще по сути является удобным узлом функциональных возможностей по работе и с документом и с задачами. Требуется ли тут разработка и кастомизация шарика? Безусловно. Этот функционал обязан быть.
Или к примеру, в стандартном функционале Sharepoint — участие пользователей в процессах — определяется учетной записью, это неудобно, поэтому переделывается на ролевое и должностное участие. Это важно, удобно и нужно. И без этого никак не обойтись. И тут конечно кастомизация логично необходима.
Но вот к примеру — требуется серьезная кастомизация в совместной работе с документом? Вовсе нет. Во первых это уже (как писалось выше) — реализовано самим Microsoft (и реализовано хорошо), а во вторых — это сильно усложнит систему в плане дальнейших доработок самим заказчиком. Вот такие вещи требуется очень четко отличать. Поскольку опять же — за непонимание этого момента — вы заплатите сейчас, заплатите потом и заплатите еще много раз.
Неоднократно сталкивались с моментом, когда к нам обращался заказчик с просьбой помочь в доработках уже приобретенного и внедренного им решения другой компанией (притом что сервис обеспечиваемый этой компанией — заказчику в общем то нравился). При уточнении обстоятельств — прояснялось — что цена на требуемые доработки, составляла пропорционально примерно 300-400% от первоначальной стоимости продукта (кстати не особо сложные доработки). За последний месяц — три крупные компании обращались за подобными услугами и всем троим менеджеру (сквозь слезы, крики и вопли) — пришлось отказать в сотрудничестве.
Но к сожалению сделать в такой ситуации практически ничего нельзя. Исходников нет и доступов к коду нет, а переписывать функциональные модули заново — конечно по цене будет очень затратно для заказчика с которого по сути уже «все сливки» — были сняты расторопным менеджером разработчика. Тут существует еще один тонкий момент: Разработчику всегда выгоднее продать свое коробочное решение пяти заказчикам в сумме за минимальную цену, нежели чем возится с одним клиентом у которого будет поставка одного готового решения + доработки по нему. Так как доработки могут занять долгие месяцы (к примеру полгода) — а внедрение готового решения занимает пару тройку недель. Итого — допустим с одного клиента с доработками разработчик получит к п примеру 1,5 млн рублей, но за то же время он может внедрить свое решение к 5-6 заказчикам без доработок и получить сумму втрое большую. Что бы исполнителю избежать этих неинтересных, с финансовой точки зрения, телодвижений — цены на доработки подбиваются максимально расплывчато и недокументировано, а после внедрения готового решения — выставляется смета и счет на колоссальную сумму, что бы у клиента даже мысли не возникло обращаться за доработками к этому же подрядчику. Ну все правильно — основная сумма с заказчика снята, а все остальное он уже пусть сам расхлебывает. Притом — выглядит все совершенно честно и прозрачно:) Не подкопаешься.
Общий вывод можно подразделить на два блока, притом второй и третий пункты аккуратненько выплывают из самой сути первого:
1. Обязательно надо понимать степень кастомизации покупаемого решения и степень возможностей доработок своими силами (при возникших потребностях), т.к это может наложить в дальнейшем отпечаток на всю стратегию развития проекта в компании на годы вперед. Притом финансовый аспект тут будет более весомый нежели чем все остальное. Зная что вы можете всегда плюнуть в морду этому разработчику и пойти к другому, всегда как то будете себя чувствовать увереннее в завтрашнем дне.
2. Обязательно документально закреплять перед оплатой и началом проекта — сумму и сроки всех будущих особенностей доработок которые могут понадобится компании. И помнить — что ваши доработки предполагаемому разработчику, на фиг не нужны — как бы он не рассыпался в сладострастных речах об обратном. Купили — развернули — выгрузили пользователей — запустили.оттестировали и до свидания!
3. При серьезности проекта, обсуждать с коллегами и руководством возможность приобретения исходников к вашему проекту, притом очень часто цена за исходники (хотя вряд ли хоть кто то согласиться их продать) может быть хоть и существенной, но тем не менее в мировом масштабе будет для вас намного более выгодной чем потом бегать по рынку и искать подрядчиков на доработки или втридорога осуществлять их у первоначального подрядчика. Пусть исходники будут за семью печатями, а в договоре будет прописана драконовская сумма штрафа за их утечку, но это всегда будет вашей возможностью экономить в будущем средства для развития проекта.
6. Насколько продукт может быть связан и интегрирован в будущем с другими решениями Microsoft в вашей компании (Корпоративный портал, Lync, Exchange и т.д.)
Это тоже достаточно важно — поскольку, часто разработчики делают «решение в себе» — и чего там понаверчено, при всей своей визуальной привлекательности для клиента, черт его знает. А значит важно знать насколько вяжется данное коробочное решение со сторонними продуктами Microsoft. Поскольку сразу в моменте внедрения — вы не сможете это понять, а когда решите к примеру привязать решение к Exchange — может всплыть боооольшой сюрприз. Но это всплывет после того как все будет закрыто по актам и паруса корабля разработчика уже скрылись за безбрежным горизонтом. Так что тут тоже надо быть повнимательнее.
Коробочные решения (для примера):
http://www.sharepoint-project.ru
http://www.ittilan.ru
http://www.wss-consulting.ru
http://www.deskwork.ru
http://www.conteq.ru
Чуть позже — продолжу.
Автор: anigillator
