На чём лучше делать информационную систему в компании?

Понадобилось подобрать инструмент для реализации информационной системы для внутренних нужд компании, и, в идеале, оценить время и стоимость. Поскольку опыта создания таких систем у меня практически нет, хочу дополнительно проконсультироваться с сообществом.

Как это всё должно примерно работать

Есть компания. У компании есть проекты. Проект ведёт сотрудник, по ходу работы с проектом ассоциируется набор товаров для закупки и их количество. Товары эти сотрудник берёт из каталога, который наполняется самими сотрудниками, так что если нужного товара в каталоге нет, он его может создать и затем ассоциировать с проектом. На странице проекта он также загружает файл с документацией по проекту, который периодически обновляет, загружая заново, при этом система хранит только последний (т.е. наиболее позднюю версию). Формат экзотический, поэтому о версионировании и иногда даже текстовом отображении можно не думать. Когда подготовка проекта завершена, на его страницу сотрудник загружает скан документа о согласовании с руководителями (PDF, отдельно от документации!) и меняет статус на, скажем, «Готов к реализации».


Лог операций по проекту отображаются на его странице: 10.10.2012 13:37 Мстислав Великий загрузил файл документации, 11.10.2012 07:40 Ицхак Аркадьевич изменил статус проекта на «Готов к реализации», и т.д.


Со сменой статуса проекта в дело вступают другие сотрудники =) Им важно, что надо закупить и сколько. Кроме того, по конкретному проекту товаров к закупке может быть малое количество, что делает их заказ невыгодным. Поэтому товары по всем проектам с нужным статусом агрегируются и отображаются на отдельной странице. По факту закупки сотрудники вносят информацию в систему. Иными словами, создают запись, ассоциированную с товаром, указывают количество, и это учитывается на странице со списком товаров к закупке. По факту получения товара эта запись обновляется (т.е. закупка получает статус «Успешно завершена»). Чтобы знать, что есть на складе, товары (и их количество) из успешно завершённых закупок отображаются на отдельной странице.


Товары затем распределяются по проектам и те собственно реализуются, но пока об отражении этого в рамках ИС речи не идёт.

Главный вопрос

Как это лучше реализовать: писать совсем с нуля, или на базе лёгкого фреймворка, или чего потяжелее (вроде Symfony, ZF), или использовать ещё более готовый Drupal, или другую CMS/CMF? Или вообще что-то совсем другое (т.е., может, я не туда смотрю)?

Вопросы со звёздочкой =)
  • Как оценить время при реализации в одиночку (может, будет несколько, но для оценки пока один)? Я думаю о примерно 3-4 месяцах. Я здоров?
  • Как оценить стоимость? Ясно, что минимум это рыночная зарплата, умноженная на время, а максимум — ресурсы заказчика. Как найти баланс? За сколько вообще продаются такие вещи, есть у кого опыт?



Я понимаю, что ответ в значительной степени зависит от бэкграунда (расхожее «в чём лучше разбираешься, на том и делай»). Я довольно давно использую Drupal, но не очень глубоко, самому модули пока не приходилось писать, хотя примерно представляю, что там и как. Использовал PHP-фреймворки, но лёгкие, а не Symfony и ZF (даже писал что-то вроде небольшой CRM). Т.е. я не ниндзя =) В конце концов, возможно, реализацией буду заниматься вообще не я или не я один, я же пока оцениваю, а опыта в таких системах не хватает — потому и нужна экспертиза сообщества.


Спасибо за внимание, буду рад услышать любые советы и мнения.
  • Вопрос задан
  • 6928 просмотров
Пригласить эксперта
Ответы на вопрос 6
Ничего сложного в ТЗ не увидел. Пользователи, проекты, каталог. Немного не понял момент распределения товаров, но, думаю, тут тоже ничего сложного.

Исходя из моего «бэкграунда» — codeigniter пойдет (как я понял, Вы ориентируетесь на PHP).

Можно попытаться подпилить какое-то готовое решение системы проект-менеджмента, но в этом вопросе не подскажу, т.к. люблю redmine, а он на ruby. Каталога товаров там нет никакого, но зато есть весь остальной функционал.

Если вернуться к идее самописа — повторюсь, ничего сложного не вижу. Идеальным решением, думаю, будет выбрать легкий движок проект-менеджмента и допилить тему с товарами и их статусами (фактически, каждый товар — это подзадача, если уж очень грубо прикинуть). В терминологии redmine — это может быть связанной задачей.

Например, есть некий проект «новогодняя акция ШОКОЛАДКА И УТЮГ В ПОДАРОК» (контекста не знаю, привожу лишь вымышленный пример). В таком случае связанными задачами будет «закупить шоколадки», «закупить утюги». У каждой из задач покупки будет описание и статусы (закуплено полностью, итп). Вот и все :)

Т.е. мое предложение — провести ресерч по готовым предложениям и прикинуть сложность доработки. Если найдется вариант, в котором есть типизированные задачи, то сделать тип задач «закупка» должно быть не трудно.

По трудозатратам с нуля 1-1.5 (вся авторизация с правами доступа, проекты, каталог). Это пессимистичный расчет. На рынке фриланса можно найти и более быстрые решения, думаю.
Ответ написан
@Vampiro
Если решение нишевое, то имеет смысл делать самописное, чтобы потом его продвигать в этой нише и отбить часть средств.

Если сильно кастомное, то вполне можно сделать доработку чего-то готового. Но не забывайте о поддержке. Когда Вам понадобится что-то поменять, найти программиста, способного найти косяки в получившейся штуке будет сложновасто.

Оценить время может только разработчик, поскольку то что один сможет сделать за 6 часов, второй будет клепать три дня. =/
Ответ написан
Комментировать
foxmuldercp
@foxmuldercp
Системный администратор, программист, фотограф
Можно еще попробовать посмотреть в сторону некоторых систем документооборота и взять некоторые вещи оттуда, хотя обычно идет интеграция их с менеджментом проектов
Ответ написан
danielnewman
@danielnewman
Front-end
В схожей заморочке. Вклинюсь.

Что в банковском секторе (даже в топ-10 банках РФ), что в энтерпрайзах (тут еще шире круг), очень часто простые задачи решаются пачками софта, десятками открытых окон в одном сеансе работе и т.д., что доставляет хлопоты всем. Хотя там (в большоам бизнесе) и бюджеты и специалисты — все есть. Почему там такой дурдом — тема отдельной статьи… УКРФ )

По идее, есть некоторые «идеологии» типа ERP, CRM и т.д., в которых заключены некоторые бизнес-модели, как в хорошей CMS есть свои контент-модели, свои элементарные единицы информации (пост, нода и т.д.) и их базовые свойства (дата поста/ноды, её заголовок, автор, рубрика, тэги и т.д.), а так же методы работы с этими единицами данных. Простите за терминологический мусор, но я — не архитектор.

Есть интерфейсы (UI), для отображения списка постов, таксономий, авторов и т.д. и мы тоже смотрим в сторону CMS, как хребта для будущей системы. Конечно, мне приходилось видеть всякие переделки CMS, но вот представить как в той же Joomla будет уродливо смотреться перекуроченный нашей логикой архаичный жесткий интерфейс с новыми «плюшками» — мороз по коже.

Про Drupal — вообще молчу, т.к. не трогаю его именно из-за его интерфейса. Отсутствия интерфейса. Хотя, может за последние два года там все изменилось (большое сомнение).

Логично предположить, что специально для задач ERP (если это тот термин) должны быть схожие открытые решения, с их моделями, основанными на практики, свои интерфейсы и логика. Что бы сразу была своя «идея таксономии» на уровне ядра и не пришлось, по неведению, её изобретать с чистого листа. Ну и своя бизнес-логика, естественно, там должна быть. А все эти разговоры о том, что на Drupal можно 1C написать, а на C++ (с вот именно этим крутым фреймвроком) — написать свой SAP… ) Давайте реально смотреть на жизнь.

Как и у автора поста, вопрос, в терминологии CMS, напоминает 1001 раз заданный на хабре прежде и звучит следующим образом: «стоит ли использовать готовую CMS или писать с нуля». Все эти разговоры, по факту, приходят к одним и тем же выводам, что лучше пилить чужой CMF/Framework, если нет опыта написания своего ряда успешного CMS/CMF/Framework с десятком внедрений. Неизбежно вспоминают руби, симфони и даже уйй. Ну и люто минусуют за предложение писать .NET приложение. Все расходятся с тем же мнением, с которым зашли комментировать, автор вопроса ничего не выбирает, но все классно потусовались. )

Разговор в тех вопросах, конечно, идет про сайты, но суть — идентична. Следовательно, выводы должны быть очень близки. Идея о том, что Joomla/Droopal — достаточные CMF… Ну, может Drupal, но это монструозное решение, покрывающее лишь 20% существующих сформулированных задач, т.к. относится немного к другому классу решений, награждает избыточным тяжелейшем функциональным мусором и лишней бизнес-логикой из другой оперы. (Тут могу преувеличить реальную проблему). Кстати, Wordpress тоже называют в википедии CMF (хе-хе). А в еженедельном топике «лучшие посты» есть ToDo List-приложение на wordpress. Сам я — поклонник вордпресса, но не хочется напильником строить забор. Даже думать об этом не хочется.

Если вопрос не загнется, очень хотелось бы услышать о реально существующих и применяющихся решениях, с комьюнити, апи, практиками и всеми теми благами, что есть в ныне здравствующей тройки CMS, потому что идея писать с ноля ERP без понимания всех существующих бизнес-логик (в смысле реального бизнеса, а не программистского) и моделей… Если с ноля, то нужно от чего-то отталкиваться, а иначе это как впервые в жизни зайти в интернет и за 1,5 месяца написать свою действительно хорошую CMS

Простите за много букв. Больная тема.)
Ответ написан
Из сочинения очевидно: нужен модерируемый псевдо магазин.

Модерируемый — потому что права на изменнеи статуса имеются у многих, возможности изменять\добавлять.
Псевдо — потому что это не столь магазин, сколько система учёта и коммуникации.

В сборках магазинных, для Drupal, есть подобный и более интересный функционал. Есть и огромный коллектив поддержки — русская, английская, белорусская, украинская, молдавская даже, и возможости шикарные. Возможно обойтись и без написания модулей, если несколько раз отфильтровать мысли ТЗ и структурировать в тезисах.

Галактический голос в сторону упрощения, Drupal. ;)
Ответ написан
По поводу оценки ресурсов — имеет смысл прикинуть кол-во и сложность основных модулей и считать исходя из них. Думаю, вашего опыта должно быть достаточно. Полученный результат имеет смысл сразу умножить на 1.2-1.5.

Точно так же с деньгами — время умножаем на среднерыночную стоимость (допустим, из расчета 10-12 долл/час). И тоже умножаем на 1.2 :)
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы