Tag Archive for Negocios

Opciones estratégicas para la Reingeniería de la Empresa

Un primer paso la planeación del recurso de la empresa es la reingeniería, el descenso, el ascenso o por otra parte los procesos de negocios modernos en el seguimiento de una ventaja competitiva o mayor eficacia. Este proceso, es llamado a veces reingeniería de la empresa, promete recompensas grandes pero también tiene grandes riesgos.

Las iniciativas de ER empiezan con una estrategia planeada para modernizar e integrar las operaciones de la compañía. Las opciones siguientes describen una visión de opciones estratégicas disponibles para reorganizar los procesos de negocios de una compañía.

La  centralización  Funcional.  Esta   opción   asigna   que   una   sola   unidad orgánica  realiza  todas  las  funciones  comerciales  comunes,  como  recursos humanos  o  contabilidad.La     estandarización     o     normalización     Funcional.     Tomando      un acercamiento    clonando,    esta    opción    tiene    un    proceso    de    negocios conveniente  de  toda  la  unidad  de  negocios  y  modelo  que  la  uniformidad en  la  implementación  de  los  Sistemas  de  Tecnologías  de  Información.  La estandarización  funcional  implica  que  una  compañía  debe  regularizar  en las  plataformas  del  hardware,  elige  una  colección  normal  de  paquetes  de ERP,  entonces  cambia  cada  uno  y  cada  unidad  comercial  a  esas  normas.

Clasificación  de  la  especialización  funcional.  Esta  opción  designa  una unidad   comercial   seleccionada   como   un   centro   de   excelencia   para   una función  comercial  específica;  la  unidad  seleccionada  realiza  esa  función para  la  corporación  entera.  La  especialización  funcional  parcial  permite  a cada  unidad  comercial  controlar  su  propio  centro  MIS  de  funciones,  como ventas  que  procesan  e  inventario  del  mando,  pero  también  centraliza  una aplicación  limitada  de  funciones  comerciales,  como  la  contabilidad,  por  la compañía.

La  autonomía  de  la  unidad  comercial  Funcional.  Esta  trasladando  la opción descentralizándola   del   acercamiento   de   empresa   no   integrada, mientras  permite  a  cada  unidad  seguir  su  propio  camino.

El  rediseño  Radical  de  procesos  comerciales.  Una  organización  podría escoger  esta  opción  en  respuesta  a  un  cambio  del  paradigma  en  que  un nuevo  acercamiento  reemplaza  al  flujo  comercial  normal.

Las  estrategias  híbridas  combinan  rasgos  de  estas  opciones  básicas. Por  ejemplo,  usted  puede  coordinar  la  regularización  libremente,  mientras permite  a  cada  unidad  comercial  para  seguir  una  estrategia  independiente de  Tecnologías  de  Información,  pero  insistiendo  que  aun  coopere  con  la unidad  comercial  en  la  mayor  parte  del  hardware  y  compras  del  software.

MANEJO DE RIESGOS ERP

Basado en experiencias con proyectos ERP en los 1990s, se ha encontrado que para que tu proyecto tenga éxito, debes prevenir problemas en las siguientes áreas altamente prioritarias:

*              Estrategia  de  negocios  electrónicos,

*              Aproximación  al  manejo  del  proyecto,

*              Tecnología  y  sistemas  complejos,  y

*              Resistencia  del  usuario  final.

Una pequeña inversión en la comprensión, análisis, rastreo, y prevención de estos principales problemas deberían costearse dado que la mayoría de tales problemas son comunes, esperados, evitables, y detectables tempranamente. Una aproximación viable para reducir la probable falla es identificar los riesgos cruciales en cada punto del ciclo de vida del proyecto, luego construir planes para dirigirlos antes que se conviertan en problemas reales. He encontrado que esta técnica es útil en la evaluación de proyectos ERP y espero completamente que sea útil también para la evaluación de proyectos de sistemas de negocios electrónicos.

La tecnología Midleware y el ERP

La tecnología Midleware ha emergido como el gluten para ser interfaz de estos sistemas y aplicaciones sobre un sistema ERP distribuido. Puedes seleccionar de varios accesos estándar -basado en CORBA, DCOM (Modelo distribuido componente objeto), y otras arquitecturas distribuidas- o desarrollar tu propia. Entérese que los mensajes buggy cliente-servidor o tecnologías objeto compartidas llevaran el sistema entero a un punto de parada.

La mayoría de paquetes ERP no cubren todos los requerimientos de negocios específicos, y por lo tanto puedes necesitar una cierta cantidad de acostumbramiento para completar el ajuste. En algunos proyectos incómodos, el desarrollo de código personalizado se inició sin suficiente meditación y planificación. El subsecuente desarrollo indisciplinado producido por el código de pobre calidad con efectos inesperados, lado no localizado, que se presento de la pobre estructura. El código personalizado también eleva significativamente el costo total de la propiedad del sistema ERP sobre el largo arrastre debido a que las tiendas IT deben actualizar las adaptaciones cada vez que un vendedor actualiza el paquete base ERP.

Una vez que un sistema ERP esta completamente cargado con los datos corporativos necesarios y cientos o miles de personas comienzan a utilizarlo, el desempeño puede sufrir si no haz diseñado por escalabilidad. Los usuarios que deben esperar mas que unos pocos segundos para ver los resultados de su ingreso en la pantalla no estarán felices.

PROBLEMAS DE USUARIO EN ERP

Servicios financieros de la Firma Deloitte & Touche condujeron entrevistas en profundidad con 164 individuos en 62 destinos – 500 compañías (La revisión, maximizar el valor de procesos facilitados ERP, Deloitte & Touche, 18 Enero, 1999). Todas las compañías incluyeron en el reporte productos manufacturados al consumidor, y todos utilizan sistemas ERP de vendedores tales como SAAP, Baan, Oracle, y PeopleSoft. El estudio se centro en marcha en vivo: aquel punto cuando el sistema ERP se hace disponible para uso general dentro de la compañía.

El estudio concluyó que cuando ocurren eventos y obstáculos antes de la marcha en vivo, ellos lo hacen de esta manera por las siguientes razones y en las proporciones reportadas (los valores listados del reporte no hacen el 100% total):

*              Obstáculos  de  la  gente,  62  por  ciento;

*              Cuestiones  de  procesos  de  negocios,  16  por  ciento;  y

*              Cuestiones  de  tecnología  de  la  información  (técnicas),  12  por  ciento.

Después de la marcha en vivo, la cuestión de gente dominaba aun, pero el énfasis de interés cambio a áreas tales como soporte de avance, desempeño de los negocios, reporte, transición del sistema, y entrenamiento. Dentro de asuntos IT, sólo cerca del 5 por ciento de entrevistados consideraron la funcionalidad del software un obstáculo antes y después de la marcha en vivo.

Desafortunadamente, el punto en el cual un proyecto debería ir en vivo no esta universalmente definido y no siempre puede ser una firma piedra sobre la base de criterios rigurosamente preestablecidos. A pesar de las proporciones relativas citadas por los problemas identificados, el impacto de estos problemas no ocurren en las mismas proporciones. Así, la manera como tú tratas con estos obstáculos puede ser la gran diferencia.

Significativamente, los sistemas que sufrieron problemas cuando marcharon en vivo fueron el mejor de todos – los únicos que sobrevivieron la mayoría de los procesos, manejo, y riesgos de tecnología que anularon muchos otros proyectos antes que puedan salir en vivo. Así, no es realmente una sorpresa que los asuntos que permanecen que confrontaron estos proyectos involucraron problemas de gente.

PROBLEMAS DOCUMENTADOS ERP

Desde el comienzo de los 1990s, muchas compañías world wide han intentado implementar sistemas ERP y fallaron. Revistas como Fortune, Datamation, e Information Week han publicado artículos sobre estas fallas. Esta publicidad ha creado la percepción que los proyectos de implementación ERP grandes son peligrosamente propensos a fallas. Para apoyar mi trabajo de consulta, he acumulado un gran compendio de tales fallas.

Considere el siguiente extracto del Harvard Business Review (Thomas H. Davenport, “Colocando la Empresa dentro del Sistema Empresarial”, Julio/Agosto, 1998, p.2).

Los sistemas ERP son costosos y difíciles de implementar. El crecimiento del número de historias de horror acerca de proyectos fallados o fuera de control deberían dar pausa a los administradores… Los problemas más grandes son problemas de negocios. Las compañías fallan en reconciliar los imperativos tecnológicos del sistema empresarial con las necesidades de negocios de la empresa misma. Los sistemas ERP se parecen a muchos otros sistemas IT grandes, complejos, sofisticados. Extremadamente riesgoso y propenso a fallas paracomenzar con, un sistema ERP por su corte muy natural de mayor riesgo que otros tipos de sistemas, como lo muestra el comentario siguiente (Susan Conner, “Y el teclado esta conectado a la base”, Chemistry and Industry, 18 mayo 1998, pp. 1-2):

“El problema más obvio con las implementaciones ERP es que estos proyectos son demasiado grandes y demasiado complejos que tu no puedes hablar de la implementación del software separado de la reingeniería de los negocios”.

Estas complejidades pueden causar problemas con el manejo, usuarios, y eventos técnicos.