Wednesday, October 09, 2013

Some thoughts about IT Development Strategy


It is commonly accepted that the definition of Strategy is a high level plan to achieve one or more goals under conditions of uncertainty.

By the definition, we can tell at least two things: first, that there cannot be a “magic bullet” because you have to define your goal before defining the strategy and the goals may vary between enterprises. And the second thing is that it is not going to be easy because of the uncertainty factor.

So, What can we do?. Software Engineering has tried, for some years now, to find an answer. Many methodologies like ITIL, CMMI, COBIT or lately TOGAF have proved very useful to better manage the IT departments and somehow they also helped with the strategy. All of them promise to “add value” because the role of IT is changing from being a support department to be the core of the business. In fact many IT terms has been applied to business (Service Oriented Enterprise, Process Focused Organization,…).

It is not my intention to make a digression about the several methodologies currently in the market, nor about the different organization’s types. I’d rather express my personal beliefs based on my own experience even though they don’t match with any methodology and they are nothing but some principles I think useful to have in mind when setting a strategy.

First principle: Simplicity. Simplicity means different things in different contexts, but applied to IT Strategy or to IT development, simplicity is related with efficiency. You probably don’t need the latest “cool” technology to do that report and you are adding an overhead any time you use something new in your technology stack (yes, you will need someone who knows about the new cool thing, pay for maintenance, patchs,…). Does it mean that you never have to use new technologies?. Short answer, NO. You have to carefully evaluate the pros and cons and I dare to say you should estimate a ROI (it can be your own flavour of ROI) as the business people do. In my opinion, simplicity should be in the DNA of any organization.

Establish a process. Some one could say, “A process?, What about simplicity?”. A process is overhead when we are taken into consideration an isolated development or only one system deployment. When we are talking about Enterprise IT, establish a process is the best way to learn what is working for you and what is not. Thus, a process is, at least, a very good information source about how you are doing and also the only way to add quality to the final product.

Promote TEAMS!. I have seen many times people working in the same place; they call it a team but they were not. Ideally, team members must have complementary backgrounds and skills, sharing common goals, have a foreseeable shared future, and share a common fate. Let’s face it. At the end of the day you have to rely on your people to do the right thing and a team is better than an individual by far. People can do amazing things working together.

Knowledge Management. Internal resources (internal teams) most often cannot cope with all the work and you have to seek help outside. That’s good in many aspects. New points of view, new skills, fresh air…. But there is one thing you never can let go. Knowledge. In your strategy, there must be a way to ensure that you do not depend on someone’s good will (establish a process and promote team working can be on handy). It is your duty to keep the situation under control at all times.

Try to have your own Royal Marine Corp (in many places known as Architecture Team). When talking about development, there’s always the requirements definition thing. The business users want something that they don’t know but they would recognize if they could see it. Well, the Royal Marine Corp can produce something very quickly. Mobility applications, Social Networking integrations, the Cloud Computing applications, you name it. When there is no time, your reduced but highly motivated and skilled team can do the job.


In summary, in my vision, there is the central principle of keep it simple, try to be reliable, your people is the most valuable thing you have, don’t lose control and sometimes you need a commando to do the dirty job.

Friday, March 11, 2011

Promotores Vs Constructores


Un tema conflictivo en cualquier organización es el coste del desarrollo IT. Es decir, ¿cuanto cuesta hacer tal o cual aplicación?. Desde la ingeniería del software se han dado varias propuestas para resolver este problema pero que, en mi modesta opinión, no sirven para el cliente que encarga el desarrollo software. Básicamente, estas técnicas de estimación están orientadas a las empresas que desarrollan software como su negocio principal, por lo que pueden conocer datos significativos como la preparación de su gente, la calidad de sus herramientas, el histórico de proyectos, etc...
El cliente que subcontrata el desarrollo no tiene nada de esto y siendo realistas, lo que suele ocurrir en la práctica, es que el cliente final pregunta a diferentes empresas de construcción de software en cuanto estiman el coste. El problema de esto es que normalmente no está definido lo que se quiere hacer por lo que las estimaciones pueden ser muy variables y además las sorpresas son frecuentes.
La propuesta que yo hago es fijarse en otros sectores. Por ejemplo, un promotor de viviendas puede ser que no tenga ni idea de cuanto vale poner 5 ventanas de doble cristal con aislante térmico de primera categoría ni falta que le hace. Lo que sí sabe es cómo es la clientela en esa zona, cuanto está dispuestos a pagar por una casa de unas determinadas calidades, cuanto debe ser el margen y cuanto está dispuesto a invertir él. Con estos datos, es ya una misión del de la constructora (que sí sabe cuanto le cuestan a él las ventanas) el dar una memoria de calidades y un presupuesto

Wednesday, March 09, 2011

El E-Commerce


No pretendo disertar en este blog sobre el significado del E-Commerce ni sobre sus posibilidades. Se han escrito Teras de información sobre este particular así que no creo que yo pueda aportar mucho en este campo.
Lo que sí me gustaría es reflexionar un poco sobre el E-Commerce y su relación con el concepto de "aldea global". En nuestras ciudades y pueblos, lo normal es que haya una carnicería en el barrio y una panadería y una joyería....Si la población es suficiente incluso se pueden especializar estos comercios y hacer que aparezcan más. Por ejemplo, puede haber pastelería y panadería, a veces dos de cada pero es muy raro que haya cuatro o cinco, ¿no?.
Pues en el E-Commerce yo creo que va a pasar lo mismo. Si la logística no lo impide veremos dos o tres tiendas de cada ramo en todo el mundo, seguramente la más competitivas (ya sabéis, la mano invisible del mercado). El resto simplemente no tiene sitio.

Thursday, February 18, 2010

Aplicaciones en USB revisited


Lockheed Martin ha ido un paso más allá de lo que proponíamos en este post y ha decidido que su personal en movilidad no use portátiles si no llaves USB con un sistemas operativo propio y con mecanismos de cifrado para garantizar la privacidad.
En este artículo podéis ver más información sobre la funcionalidad de estos dispositivos.

Wednesday, October 07, 2009

Aplicaciones autocontenidas en una llave USB



En la página portableapps nos explican como podemos llevarnos nuestros programas favoritos de un pc a otro. Para un usuario particular esto puede ser útil si por lo que sea tiene que usar varios pcs y no le interesa instalar todo el software que necesita en todos y cada uno de los pcs.
Para una empresa, las aplicaciones portables pueden tener otra dimensión. Le permite extender su sistema informático a otros empresas. Es decir, si por alguna funcionalidad de negocio hay que darle una aplicación a otra empresa, no se tendría que instalar el software en una máquina de esta segunda empresa. Se podría dar la aplicación en un USB con todo lo necesario para que funcione.

Se podría alegar que al entregar el software en un USB el cliente lo podría copiar al disco duro, a otro usb, etc, y de alguna manera romper la ventaja de tener un entorno autocontenido. Pues bien, con un simple script en Visual Basic se pueden hacer una serie de comprobaciones que aseguren que el código se está ejecutando en la llave USB correcta, por ejemplo, una unidad de nombre "XXXXX" y un determinado número de serie. Pego un código de ejemplo:

strComputer = "."


' Obtención de la letra de unidad


Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")


' Comprobación de S/N del fabricande del HW

' Cogemos el número del fichero
Const ForReading = 1
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTextFile = objFSO.OpenTextFile _
("configuracion.properties", ForReading)
strNextLine = objTextFile.Readline
arrServiceList = Split(strNextLine , ",")
SnFichero = arrServiceList(0)

' Hacemos la búsqueda entre los dispositivos físicos conectados al equipo
Set colDevices = objWMIService.ExecQuery _
("Select * From Win32_DiskDrive Where InterfaceType='USB' and PNPDeviceID like '%" & SnFichero & "%'")

if colDevices.count = 0 then ' No hemos encontrado el dispositivo
Wscript.Echo "El dispositivo de nombre XXXXX no está conectado."
else ' El dispositivo existe
Wscript.Echo "El dispositivo de nombre XXXXX está conectado."

' Comprobación de los datos de la unidad lógica asociada al pendrive
Set colDisks = objWMIService.ExecQuery _
("Select * from Win32_LogicalDisk where VolumeName='XXXXX'")
if colDisks.count = 0 then ' No hemos encontrado la unidad lógica
Wscript.Echo "Se ha modificado el nombre del dispositivo de XXXXX."
else ' La unidad lógica existe
For Each objDisk in colDisks
letraUnidad = objDisk.Name
Set colProcesses = objWMIService.ExecQuery( _
"select * from win32_process Where Name = 'Wscript.exe'" )
For Each objProcess in colProcesses
rutaEjecutable = objProcess.CommandLine
' Buscamos la letra de unidad en la ruta de ejecución del proceso
resultado = instr(rutaEjecutable,letraunidad & "\script\Def4.vbs")
' Wscript.Echo letraUnidad & " - " & rutaEjecutable
Wscript.Echo "Ruta de ejecución del script: " & rutaEjecutable & VbCr & "Letra de unidad XXXXX: " & letraunidad
if resultado <> 0 Then
Wscript.Echo "Se está ejecutando en el pendrive."
else Wscript.Echo "NO Se está ejecutando en el pendrive."
end if
Next
next
end if
end if

Tuesday, June 16, 2009

El ROI en la inversiones tecnológicas


En algún post como éste, contaba mi modesta opinión sobre añadir herramientas informáticas sin pararse a pensar en el proceso subyacente. Hoy me he encontrado este artículo en donde se va un poco más allá y se afirma que no existe ROI en realizar inversiones puramente tecnológicas.

¿Entonces, cómo decidir abordar un proyecto tecnológico?. Llevado el argumento al absurdo, si no hay retorno de la inversión, nunca se debería realizar ningún proyecto tecnológico, ¿no?. Pues bien, y aquí está el quid del asunto, lo que se dice en el artículo es que el ROI existirá en la medida en la que la tecnología pueda cambiar la naturaleza del trabajo realizado y este cambio se puede medir con elementos más o menos familiares a las empresas como son los cuadros de mando que muestran el "Business Performance".


En definitiva, y aunque tire piedras sobre mi propio tejado, no puedo hacer otra cosa que estar de acuerdo con el autor del artículo y personalmente he asistido a muchos despliegues de herramientas en donde todo el mundo estaba empeñado en que no se debía cambiar la forma de hacer las cosas y el objetivo era adaptar la herramienta a lo que ya se estaba haciendo, costase lo que costase.


Como me dijo una vez un compañero, un clavo lo puedes clavar con una piedra pero si tienes un martillo.... Yo añadiría, ¿de verdad tienes que usar un clavo?.

Tuesday, May 19, 2009

El directivo perfecto


El autor americano Lawrence Miller en su libro Barbarians to Bureaucrats habla de unos perfiles directivos que denomina el profeta, el bárbaro y el administrador.

El profeta encarna la fé ciega. Es el entusiasmo en su máximo grado, las nuevas ideas, no le interesan los estudios ni los análisis concienzudos, la verdad le ha sido revelada y su misión es transmitirla a todos los que están con él. Este tipo de directivo es el que se necesita al comienzo de toda actividad (por ejemplo, el cambio de aplicaciones informáticas propietarias a otras open source) ya que se necesita un alto grado de motivación para sobreponerse a las resistencias que todo cambio genera.

El siguiente paso sería el directivo bárbaro. Este no tiene la capacidad de generar ideas como el profeta pero tiene un objetivo claro y nada ni nadie le va a apartar de conseguirlo. Típicamente en informática, este directivo sería capaz de enfrentarse a los usuarios, al departamento financiero y si se tercia al consejo de administración. Por supuesto, no le hablemos de normas, ni de planificación. La ley es él (y también la policia y la administración de justicia). Sus métodos puede que no sean ortodoxos pero es lo que se necesita para que la organización crezca y sea competitiva. Ahora bien, cuidado porque la eficacia del bárbaro está limitada en el tiempo.

El tercer tipo de directivo sería el administrador. A éste le van los planes, las normas, el rigor. No es un conquistador que vaya a anexionar territorios pero la defensa está garantizada. Lo conseguido por el bárbaro, que a su vez realizó la visión del profeta, está en buenas manos con el administrador. El peligro que tiene el administrador es que la situación cambie y se necesite marcar un nuevo rumbo.

En definitiva, el directivo que consiga ser los tres modelos anteriores y en el timing justo será el directivo perfecto.

Friday, May 08, 2009

La burbuja inmobiliaria y la crisis

En algunos de los post hemos hablado de la crisis económica y de la generación de valor a través de la tecnología. En esta entrada vamos a dejar de lado la parte técnica y os voy a adjuntar un archivo hecho por un compañero en el que se explica de manera muy clara el origen de la burbuja inmobiliaria y sus consecuencias.
Que disfrutéis!

Monday, December 22, 2008

Diez lecciones para que un proyecto de IT sea un éxito



He encontrado este artículo donde se habla de los 10 punto principales para que un proyecto de IT tenga éxito. Hago una traducción libre de los mismos:

    1. Los procesos de negocio son los que deben decir qué hacer y cuando y nunca la tecnología.
    2. A veces hay que arriesgarse a cambiar la vieja y conocida tecnología por una nueva.
    3. Hay que llevar el control de los proyectos a lo largo de toda la empresa.
    4. Todos los implicados deben estar cerca y disponibles en todo momento.
    5. Hay que darle al cliente lo que quiere, no lo que nosotros (tecnólogos) nos gustaría.
    6. Hay que medirlo todo. El éxito y el fracaso.
    7. La solución más fácil no tiene por que ser la buena (aunque a menudo lo es).
    8. Ten encuenta la gestión de los datos maestros.
    9. Make a lean system even leaner (este punto no lo traduzco)
    10. Don’t use complicated, expensive software when a clipboard and pencil will do (éste tampoco).
En fin, yo añadiría a estos puntos el de "may the force be with you".

Friday, November 28, 2008

Crisis y tecnología


No hago más que escuchar por la radio a los tertulianos hablar de que uno de los principales problemas de la economía es la falta de productividad y que lo que hay que hacer es orientarse a la economía del conocimiento usando la tecnología para aportar valor.

No voy a decir yo que estén equivocados, muy al contrario, seguramente tengan razón. Ahora bien, lo de mirar a la tecnología como si fuera la panacea tiene sus riesgos. De hecho, si la implantación de cualquier herramienta tecnológica no se hace acompañada de cambios en la estructura y en los procesos puede resultar un lastre más que una ayuda. Esto que puede parecer de perogrullo, muchas veces no se entiende o no se tiene tan claro y se desarrollan sistemas o se implantan herramientas que lo único que hacen es repetir lo que ya se estaba haciendo pero de otra manera aportando, en el mejor de los casos, un valor mínimo. ¿Y esto por qué?, por que tenemos interiorizado el mantra de que la tecnología es la solución a todo y no nos damos cuenta de que la tecnología puede ser el camino pero nunca debería ser la meta.

Os dejo un enlace a un discurso bastante ilustrativo al respecto que dio el presidente de la multinacional Diageo (sector bebidas) en una conferencia sobre los Desafíos de la gestión tecnológica.

Wednesday, November 12, 2008

De IT a BT


Dicen los analistas de Forrester, que los líderes de IT deberían focalizarse en los resultados de negocio y en la innovación, no sólo en la madurez de la tecnología.

Según Forrester:

IT Excellence = Maturity + Alignment + Innovation.
Business Technology (BT) = Pervasive technology use that drives busines results.

Es decir, según la gente de Forrester, el role de IT es promover la evolución hacia BT e invertir en innovación pero en innovación de negocio. Muy bien, según esto, se quiere que el departamento de tecnología sea un habilitador del cambio y como ya hemos dicho en algún post, esto es algo no sólo deseable sino que necesario para la supervivencia del departamento de IT porque si simplemente se dedica a dar un servicio "commodity" ahí está el outsourcing.

Dicho esto, quizá también sea necesario que se cambien los criterios por los que se juzga al departamento de IT. En vez de meterle collejas porque se ha caído tal o cual aplicación igual habría que meterle collejas por que no ha propuesta nada que mejore la competitividad de la empresa.

Tuesday, November 04, 2008

La cultura corporativa


En uno de los post hablábamos de los tipos de organización y de las enfermedades organizativas. En éste, me propongo hacer un resumen de los tipos de cultura corporativa más abundantes teniendo en cuenta su entorno y su orientación de los que habla Richard L. Daft en su libro "Teoría y Diseño organizacional".

Básicamente, se distinguen las organizaciones por su entorno, si es un entorno que requiere flexibilidad o estabilidad, y por sus fortalezas y orientación, orientación interna o externa.

Así tendríamos las organizaciónes adaptables (entorno flexible, orientación externa) que se caracterizan por:
  • Ser capaces de traducir las señales del mercado
  • Estar orientadas a su cliente
  • Son proactivas no sólo reactivas
  • Son creativas y asumen riegos
Organizaciones de tipo misión (entorno estable, orientación interna):

  • Se orientan a un sector específico del mercado
  • Tienen un visión clara y se manejan bien con metas a corto
  • Suelen conseguir los objetivos (ventas, crecimiento, cuota...)
Organizaciones de tipo clan (entorno flexible, orientación interna):
  • Los empleados participan de las decisiones
  • Existe un gran sentimiento de responsabilidad y compromiso
  • Se fomenta la promoción interna
  • Se logran grandes cuotas de satisfación y productividad entre los empleados
Organizaciones de tipo burocrático (entorno estable, orientación interna):
  • Tienen enfoques metódicos y todo está procedimentado
  • Suelen hacer uso de la simbología con ceremonias, tradición, héroes.
  • Hay acuerdo tácitos en todos los ámbitos de la organización
  • Suelen ser organizaciones predecibles donde existe un gran control que evita el despilfarro
Por supuesto, casi nada es blanco o negro y las organizaciones no escapan a esta máxima. Incluso dentro de la empresa con una cultura más marcada, pueden surgir subculturas de otro tipo casi siempre de la mano de un líder. De ahí que los departamentos de TI no tengan excusas aunque estén en el ministerio más rancio del país.
Diapositiva 6


Diapositiva 5



Diapositiva 4


Thursday, October 30, 2008

Innovación y gestión del cambio


Desde hace ya algún tiempo pero con el advenimiento de la actual crisis, todavía más, se habla de que la economía del futuro se basa en el conocimiento y en la innovación. Pero, ¿qué pasa cuando un departamento de una empresa se pone a innovar?. Pues en primer lugar, probablemente se produzca un cambio de "lenguaje" en ese departamento que lo va a distanciar del resto de la empresa lo que provoca un rechazo que finalmente acaba por echar a la parte más débil (el innovador).

¿Qué se puede hacer para que esto no ocurra?. Pues se puede intentar "gestionar el cambio". Para ello hay que tener presente algunas cosas:
Cuando alguien se enfrenta a un cambio, lo primero que se sufre es miedo. Miedo a la magnitud del cambio, luego desconfianza, se empieza a pensar que para qué se va a cambiar si todo va perfectamente, pueden entrar en juego incluso emociones y que alguien se lo tome como algo personal y finalmente, puede que el cambio no sea posible por falta de capacidad para realizar el mismo (conocimiento, medios materiales, ...).

Pues bien, si se evalúa el cambio en dos ejes, se puede hablar de un eje "hard" en el que se representaría la eficiencia operativa del cambio y un eje "soft" en el que estarían los aspectos culturales de la empresa. Una primera aproximación es envolver el plan "hard" dentro del "soft". Es decir, empezar por identificar las barreras contra el cambio, da los primeros pasos, observa quién está dispuesto a seguirlos y otórgale poder o alguna clase de beneficios, da publicidad a estos logros (tanto a nivel operativo como de beneficios para los seguidores del cambio) y vuelve a repetir el proceso.

Por supuesto, este proceso tiene que estar liderado por alguien que realmente tenga potestad (y preferiblemente autoridad también) para llevarlo a cabo. Y una cosa muy importante en todos los cambios organizativos, dar sensación de "URGENCIA".

Tuesday, October 28, 2008

Hermeneutica


La Hermeneutica es el arte de la interpretación de textos para determinar la idea exacta que se quiere expresar.
Desconozco si Booch, Rumbaugh y Jacobson creadores del UML eran conocedores de la existencia de la Hermeneutica pero desde luego no les habría venido mal.

Probablemente les hubiese venido bien para evitar que el lenguaje UML carezca de una semántica precisa, lo que dificulta una interpretación objetiva de un modelo UML, que factores como serialización y persistencia, muy importantes en sistemas distribuidos no estén descritos en este lenguaje.

En fin, quizá es el momento de volver a Alejandría y plantearnos cuál es la mejor manera de transmitir ideas entre humanos.

Monday, October 27, 2008

Norma ISO 20000


Las empresas dependen cada vez más de sus sistemas de información y afortunadamente se exige cada vez más una gestión profesional de los recursos de TI. Por lo tanto, los departamentos de tecnología han desarrollado sus propias "armas defensivas" por las cuales aseguran a la organización que están haciendo lo correcto y no están malgastando la inversión que se ha hecho en infraestructura de TI.
Una de estas armas es la ISO 20000 pero, un momento, ¿no estaba siendo una tal ITIL la defensora de la virtud de los departamentos de TI?.

Bueno, en el fondo son primos hermanos. Las principales diferencias serían:

La ISO 20000 es una norma internacional respaldada por un organismos oficial (la ISO y en España AENOR) mientras que ITIL son “buenas prácticas” aunque sea el "estándar de facto".
La ISO 20000 tiene referencias al control de proveedores lo que en el actual panorama es muy importante ya que casi ninguna empresa gestiona su TI con personal 100% propio.
Los informes al comité tienen entidad propia y se considera un proceso independiente.
En ITIL no es obligatorio el plan de continuidad de negocio y la ISO 20000 incluye además la norma ISO 27001 de seguridad de la información.

Hay alguna otra diferencia pero que no dejan de ser matices sobre lo mismo.

Wednesday, October 15, 2008

Software Craftmanship


Es ya un viejo tema la posibilidad de "industrializar" la creación de software. Lo cierto es que los proyectos no suelen acabar a tiempo y normalmente no se ven usuarios pegando saltos de alegría con el producto final.

También es cierto que se han hecho muchos intentos para mejorar la creación de software usando diferentes metodologías que han obtenido resultados desiguales.

A la vista de esto, se me ocurre que a pesar de la metodología aplicada, la última línea de defensa es el programador que teclea por lo que su talento es fundamental. Es como si en una empresa de construcción de coches que usa el "just in time" el encargado de colocar las ruedas al coche no sabe donde colocarlas y le echamos la culpa al proceso. Con esto no quiero decir que la metodología no importe, que importa, si no que está claro que al final del proceso siempre está el programador.

Por otro lado, la mayoría de lenguajes empleados en la programación están hechos para que lo entiendan las personas y por supuesto las líneas de código plasman conceptos. Esto quizá diferencie la construcción de software y la de coches.

Monday, October 13, 2008

Black Swan


En el año 2007 Nassim Nicholas Taleb publicó un libro llamado "The Black Swan" (en español el cisne negro). En ese libro, expone su teoría (The black swan theory) según la cual la mayor parte de los grandes avances científicos y en general los hechos impactantes y difíciles de predecir son eventos que no deberían ocurrir (de ahí el nombre de la teoría, cisne negro, ya que se supone que los cisnes son blancos).

En el fondo, lo que Taleb nos cuenta es que aunque nos guste pensar que podemos explicar las cosas que pasan, las verdaderamente impactantes son efecto de la casualidad y no de acciones dirigidas a obtener el efecto que finalmente ha ocurrido. Taleb pone de ejemplo el auge de Internet, el ordenador personal, la Primera Guerra Mundial y el 11 de Septiembre.

No es que consuele mucho pero cuando tu sistema redundado, con recovery automático falla estrepitosamente siempre puedes decir que "también existen cisnes negros" y sino que se lo digan a Wallstreet.

Friday, October 10, 2008

La organización del departamento de IT


El departamento de IT de una empresa suele ser un lugar bastante complejo. El hecho diferencial con respecto a otras áreas de la empresa es que no sólo se da servicio a clientes externos (los otros departamentos de la empresa) sino que existen relaciones clientelares dentro del propio departamente de IT. Así por ejemplo, desarrollo es cliente de sistemas, sistemas es cliente de comunicaciones, etc...

Existe un tipo de organización del departamento de IT que es la organización por tareas en la que existen grupos especializados en una determinada función. Estos grupos siguen el modelo de caja negra, es decir, reciben inputs por un lado (peticiones) y generan outputs (las tareas realizadas).
Esto tiene muchas ventajas pero principalmente se consigue un ahorro de costes ya que con pocos recursos (pocos miembros en estos grupos especializados) se consigue atender a muchos clientes. El problema (y gordo) es que al ser una caja negra, los grupos especialista necesitan un gran detalle en la petición ya que desconocen la finalidad y el contexto en el que ésta se ha hecho.
Otro gran inconveniente es la dilución de responsabilidad. ¿De quién es la culpa de que no hayamos cumplido el plazo?, ¿la petición estaba bien hecha?, ¿le faltaba una coma y no he entendido que querían?...

Existe otra manera de organizar el departamente de IT que es la organización por proyectos. En este modelo, no existen grupos de especialistas sino que se asignan especialistas a cada proyecto. Aquí las responsabilidades están claras y todo el mundo tiene el mismo objetivo (que tu proyecto, en el que estás asignado, salga bien) pero tiene otro gran incoveniente. Se necesita más gente ergo es más caro.

Tuesday, October 07, 2008

El coste de inventario


Existe un concepto comúnmente manejado en la industria que es el coste de inventario.
Los inventarios son un conjunto de bienes o productos almacenados. Este almacenamiento funciona como un buffer que amortigua ineficiencias o errores en la cadena de suministro.
Por supuesto, las empresas conocen perfectamente que tener inventarios suponen costes. Por ejemplo tendríamos costes por la compra de los productos que forman el inventario, costes de obsolescencia, costes de manipulación, costes de ocupación y finalmente gastos varios.

Como se puede observar, el coste total es la suma de varios componentes. No siempre todos los conceptos se pueden aplicar en todas las situaciones pero el coste de inventario quizá sea aplicable a más casos de los que normalmente se consideran.
Así, se me ocurren dos preguntas:
¿Para qué quiere una empresa logística, manufacturera, industrial, etc..., un CPD?
¿Será por esto de los costes de inventario que está de moda el tema del Cloud Computing?

Thursday, October 02, 2008

LAISSER FAIRE, LAISSER PASSER


El "laisser faire, laisser passer" (dejar hacer, dejar pasar) es un término económico que está detras de la filosofía del liberalismo económico. 

Básicamente, lo que el término "lasser faire" indica, es que el máximo beneficio se obtendrá cuando todos los actores de un determinado sistema actúen libremente según sus intereses sin que nadie externo regule esta actuación. 

Estamos viendo últimamente que esta filosfía tiene sus problemas ya que en muchos casos se intenta tener un beneficio a corto plazo aunque a largo plazo esto sea el fin.

Bueno, pues algo parecido pasa en los departamentos de sistemas. Se recibe una petición de un equipo de desarrollo para hacer un pase a producción, ¿que le interesa al departamento de sistemas?, Laisser faire, laisser passer.