Adquisición de un servicio de consultora versus la propia implementacion del software - BPM & Proyectos Terminología básica BPM - BPM & Proyectos Software Gestor de proyectos - BPM & Proyectos Comenzando - BPM & Proyectos

Adquisición de un servicio de consultora versus la propia implementacion del software

No Comment


Se debe dejar en claro las diferencias y beneficios de la adquisición de un servicio de consultoría, y que cuando son basados en productos código abierto, no es exactamente gratis. Al adquirir un software el soporte en general viene de tres maneras: el libre, opensource en comunidad (este es importante para los desarrolladores); el opensource de licencia dual (que es una combinación entre libre y licenciado); así como el profesional o de consultoría (al que la empresa recurre oficialmente). La siguiente tabla ilustra diferencias entre opensource y licenciado:
Empleo de Software Libre Opensouce
Servicios duales OpenSource y/o Privados
Servicios y Consultoría Privada Profesional
“Todo es visible, con esfuerzo bien funciona”
“Todo visible, y funciona si me compras”
“Funciona excelente, pero es una caja negra”
  • Los servicios se limitan a los que hay disponible en el ámbito global, y no específicos a las necesidades de una empresa solicitante.
  • Los servicios se limitan a los que hay disponible en el ámbito global, y no específicos a las necesidades de una empresa solicitante.
  • La empresa especifica según sus requerimientos a la consultoría que es lo que necesita y esta le debe proporcionar una solución viable.
  • Entornos de producción funcionan completos, pero se limitan si son incompatibles con licencias no libres.
  • Los entornos de producción funcionan limitados si no se adquieren las licencias. Permite la combinación de licencias.
  • Se requiere licencia para entorno de producción, las cuales expiran en un tiempo determinado y entonces dejan de funcionar.
  • La estabilidad depende de la popularidad del proyecto o software, no existen garantías de funcionamiento ya que el producto se ofrece “así tal cual”.
  • La estabilidad depende del tipo de producto adquirido, si no es licenciado este depende de la popularidad respecto su contraparte licenciada.
  • Los entornos de producción son certificados estables, y si aparecen problemas la empresa responde por la eventualidad con soporte pero según los acuerdos de licencia.
  • El software no esta apadrinado ni apoyado por compromiso alguno. Su continuidad y soporte se basa en su popularidad. Por ello esta disponible el producto con su fuente.
  • El soporte y continuidad depende de la competitividad de las licencias. También parte es basada en su popularidad. Ofrecen si se adquieren licencias migraciones.
  • El software ofrece continuidad basado en las tendencias del negocio, en casos de migración, las licencias definen el alcance y soporte de apoyo y servicios ya sin uso.
  • Las herramientas de software pueden usarse en su totalidad sin restricciones, incluso modificar sus partes según las necesidades.
  • Las herramientas pueden estar restringidas si no se adquiere las licencias, pero en la mayoría de los casos ofrecen el código fuente para modificarlo según necesidades.
  • Las herramientas son modulares, mas no modificables, la consultoría se realiza bajo los estándares y tecnologías ya fabricadas, o los definidos por el servicio de consultoría.
  • Si se modifica alguna herramienta según las necesidades, los foros y comunidades ofrecen el apoyo disponible.
  • Si se modifica alguna herramienta según las necesidades, su soporte y apoyo debe estar contemplado en la licencia.
  • Es ilegal si se modifica alguna herramienta utilizada durante la consultoría, a menos se haya declarado ello.
  • Los estándares están en la red, no cambian los parámetros ni implementan nada nuevo sin aprobación de la comunidad.
  • Los estándares intentan ser mixtos, entre los abiertos y los apegados a los impuestos por grandes empresas.
  • Los estándares son seguidos incluso ofrecen soporte extra. Sin embargo, las empresas implementan “mejoras” que rompen los estándares.



Terminología básica BPM

No Comment


Terminología BPM

Esta terminología no esta ordenada alfabéticamente, su intención es actualizarla a medida crezca el contenido. Los términos aquí son basados en el estándar de BPMN y no el de BPEL.

Para el gerente y los lideres de proyectos, es la guía perfecta, y adicional primordial para entenderse con los recursos: programadores y desarrolladores. Para el programador es esencial aprenderselos de memoria.

BPM: Business Process Management.
Metodología que permite automatizar el comportamiento de la organización a través de los procesos.
BPEL: Bussines Process Execution Languaje
Es la definición de lenguaje de programación para la implementación de BPM, cualquier regla se plasma y realiza al servidor de aplicaciones empleando este lenguaje.
BPMN: Business Process Manager Notation
Definicion adicional de un lenguaje visual el cual genera el BPEL para depues desplegar la idea o regla.
BAM: Business Activity Monitoring
Capacidad de la plataforma BPM empleada para vigilar y exponer los eventos (procesos corriendo y sus resultados) del negocio en accion. Este concepto logra extenderse a otra rama, el BI.
  • Elementos BAM: son necesarios porque permiten emplear decisiones para modificar las reglas de negocios, el fin de estos son optimizar los procesos:
  • KPI’s : indicadores claves de rendimiento-
  • Dashboard: monitorizacion en tiempo real el valor actual de los KPI’s
Orquestación:
Ejecución organizada de las reglas que definen un proceso, respecto el todo del negocio.
BPMS: Business Process Management System/Suite.
Las herramientas o componentes para la construcción de aplicaciones siguiendo la metodología BPM anteriormente ilustrada.
  • Componente BPMS: Artefactos de software que permiten trabajar modularmente la tecnologia y metodología BPM.
  • Workflow:Es el motor que ejecuta/orquesta los procesos de negocio definidos, por medio de BPEL.
  • Process Designer: La herramienta que permite definir los procesos de negocio por medio de un lenguaje que se traduzca a BPEL como lo son BPMN o XPDL.
  • Form Creator: Herramienta que permite definir formularios de interacción humana donde el actor puede iniciar, rechazar, aprobar, una instancia de un proceso de negocio.
BRE: Business Rules Engine
El entorno de ejecución donde el conjunto de varias reglas de procesos se relacionadas entre si o se encuentran.
BPMS Connectors:
Los componentes que permiten dotar de tecnologías para los procesos, es decir, el BPMS define las reglas en que se trabaja, pero no la tecnología empleada, de esto se encarga los conectores. Estos pueden ser para ECM, LDAP, ESB, etc. Son cruciales en los BPMS puesto definir las reglas sin ponerlas en practica en su máxima expresión no optimiza ningún negocio.
JBPM: Java/JBoss Bussines Process Modeling
Es la tecnologia de BPM empleada en ciertos BPMS, como versiones antiguas de oracle y ahora en versiones recientes de los productos de RedHat.
WS: Web Service
Tecnologia web basada en servicios a demanda.
XPDL: XML Process Definition Language
Lenguaje alternativo de BPM

Software Gestor de proyectos

No Comment

Existen muchos, entre los privativos uno de los mas completos es Jira, enfocado en java, entre los libres Redmine esta tomando fuerza. Sin embargo estos tiene dos problemas, dependen de tecnologias no estandares y no estan sus dependencias en los hosting principales.

Todos sabemos que los proyectos estan presionados por la parte Gerencial, asi que lo siento, lastimosamente estos factores estaran molestando siempre.

Factores para implementar un software de gestion de proyecto

Que debe tener en cuenta al implementar un software de gestiion de proyecto:
  • Facil de usar
  • Entendible
  • Colaborativo
    • Soporte estimaciones
    • Soporte de tareas y tickets
    • Soporte de diagramas de grantt
    • Integrable a GIT, SVN y CVS
    • Sistema de documentacion
  • Enfoque:
    • Local interno de la empresa
    • Hosteado en un entorno empresarial o servidio externo
  • Sostenible
    • Tecnologia conocida, con soporte conocido comprobable.
    • Con soporte de alguna compañia resposable del mismo.
    • Seguro y fiable

Entre los mas usados estan Dotprojet, Jira, BaseCamp, Redmine, que integran muchos de los elementos, pero tambien estan las opciones por separado, estan no deben ser tomadas en cuenta, ay que dificultan la sotenibilidad del proyecto, el ejemplo mas famoso de estas soluciones por separado es mantis+mediawiki y sharepoint.

Los recomendados para usar aqui se clasifican en dos categorias: Internos manejados por la empresa misma o externos, y lo mas logico es que si es interno sea barato y administrado por la empresa misma.
Si la empresa emplea recursos por fuera de las instalaciones, debe optarse por tener salida y entrada segura de la red o un servicio externo de gestion de proyecto.

Gestor de proyecto interno: Redmine

Redmine es una solución flexible de vistas Web para la gestión de proyectos. Escrito el framework Ruby on Rails, Redmine es de código abierto, lo que significa que siempre se puede modificar el sistema, de acuerdo a las necesidades específicas de su empresa. El programa es multilingüe y está disponible en más de 30 idiomas. También cuenta con el apoyo de bases de datos múltiples: la aplicación está disponible en Postgre SQL, SQLite y MySQL. Esta es una imagen del redmine modificado solo a travez del tema, corriendo en Venenux 0.9 en la pestaña de control de versiones del software projecto desarrollado.


Pros:

  • Extremadamente sencillo y facil de usar
  • Diagrama de Gantt, que es la característica más esencial para la planificación del proyecto. 
  • Reportes: exporta cualqueira de las vistas en varios formatos
  • Modular:La mayoría de las características a nivel de proyecto se puede desactivar si es necesario.
  • Multiproyecto: soporta multiples proyectos y subproyectos, y adicional en una sola instancia o multiples.
  • Soporte empresarial externo: alojamiento en los servidores de Planio se inicia a partir de 9 $ por mes. Usted puede obtener una prueba gratuita de 30 días.
  • Tasklist: basado en la gestion del sistema de bugtracking, tiene sistema integrado de listas de tareas y adicional planificados.
  • Planificador: las definiciones de fin de requerimientos son gestionados en las tareas.
  • Bugtraking: incluye sistema de reporte y peticiones de incidencias.
  • Repositorios: se integra perfectamente a cuatro tipos de repositorios, siendo el que mas repositorios soporta, como git, bazar, subversion y el antiguo cvs.
Contras:
  • Es basado en tecnologia RubyOnRails y ningun hostig lo trae

Gestor de proyectos externos:

Aquí es cuando la empresa no cuenta con la infraestructura o tiene la necesidad de tener el proyecto en la nube, sea privado o publico.

Conclusiones


Redmine es el ganador obvio ya que es el que posibilita la mayor cantidad de capacidades, no perdere tiempo en compararlo con los demas ya que el colmo de los beneficios es que adicional a su facilicimo adaptacion de uso por parte de windoseros, esta el que se pueda integrar a gmail con xmpp.

Comenzando

No Comment

En un proyecto hay tres partes:

Tecnica, Funcional y gerencial.

Lo primero que hay que hacer es convencer la gerencia, para esto un proyecto debe tener factibilidad, rentabilidad y por lo general y siempre es asi, integración e histórico con las tecnologías presentes.


Cada organización tiene sus propios procesos distintos de negocios que los diferencia de sus competidores. Nuestro caso es relativo a muchos procesos que son definidos por los propios trabajadores. La integración al unisono es una de las metas para la efectividad y productividad.

  • Atención al cliente (tiendas, modo entandar de trabajo y acopio)
  • Control de calidad (efectividad del producto respecto el mercado y la competencia)
  • Requerimientos (insumo, equipos, consumibles)
  • Administración (caja chica, contratación de recursos)

Minutas a tomar en cuenta al comenzar un proyecto:


  • No debe costar mucho.
  • No debe ser complicado de implementar.
  • Debe ser rapido de desarrollar o construir.
  • Debe tomarse en cuenta los riesgos de que se complete.
  • Debe tener en cuenta la tecnologia empleada.
  • Debe ser factible de emplear sus componentes y recursos en el tiempo que dure.
  • Sus componentes y recursos depen perdurar un tiempo despues de la culminacion de su desarrollo.

Esto son principios esenciales.

La parte tecnologica es importante, determina y ayuda mucho en la organizacion.

© 2012. All Rights Reserved. Blue Marine Blogger Templates is created by: PICCORO Lenz McKAY and