mencionámolo nunha entrada anterior sobre a elección do mellor software, no que nos centramosanálise preliminar do propio negocio corporativo (sen o cal non é posible facer unha elección sabia). Tamén veremos que, para unha boa selección, hai que considerar un número limitado de vendedores. Para logo analizar non só as solucións desde un punto de vista "técnico", senón tamén os servizos que ofrecen e a organización de recursos humanos que, dentro da nosa empresa, serán necesarios para sacar o máximo proveito do novo software. Se non, gastaremos mal o noso diñeiro ao non obter os beneficios desexados.
Agora imos dar un paso atrás e preguntarnos cales requisitos funcionais e cales como mercar haberá que presentar a solución ideal para as nosas necesidades: en definitiva, cales son os principais beneficios que esperamos atopar no mellor software. Tamén neste caso, en canto á análise preliminar do noso negocio, non teremos en conta ningún produto ou especificacións técnicas en particular: este será o seguinte paso. Polo de agora, só completaremos unha lista de verificación cos elementos que hai que "marcar" que serán útiles nos seguintes pasos.
"Preguntámonos cales requisitos funcionais e cales como mercar terá que presentar a solución ideal para as nosas necesidades: en definitiva, cales son os principais beneficios que esperamos atopar no mellor software "
E tamén neste caso, o noso lista de tarefas articúlase e implica máis tomadores de decisións interna para a nosa empresa: certamente non só o departamento de TI.
La selección de software de clase empresarial pode ser o efecto dunha necesidade, manifestada por un sector interno da nosa empresa, ou un mandato directo da mesma alta dirección (que ten unha visión global dos intereses futuros da empresa e da estratexia a seguir). A orixe do propio mandato depende en gran medida de se o proceso que se está a considerar núcleo ou secundario ao negocio. Lembrar que a elección dun novo software é a clave para cambiar os procesos.
En calquera caso, o que realmente importa é iso todo actores implicados (incluídos os que manifestan a necesidade, os que toman decisións aos máis altos niveis e os que dispoñen das habilidades técnicas e funcionais para levar a cabo futuras negociacións) aliñados co propósito da selección e sobre as características da solución para ser adquirido.
Só con estes supostos podemos de feito redactar o lista de requisitos funcionais. O ideal sería que os nosos tres actores (usuarios, directivos e analistas técnico-funcionais) se unan para un negocio común de de brainstorming. Sen dúbida, esta posibilidade depende da variable tempo (é necesario ter en conta os custos internos para o definición e xestión de a proxecto).
E esta actividade de aliñamento é aínda máis importante se temos en conta un aspecto máis da selección: como en todos "A viaxe do comprador", é dicir, o proceso de compra que comeza a partir dunha necesidade e pasa pola recuperación de información sobre a oferta do mercado, pode haber algúns "Zonas grises". En realidade, non é raro que a alta dirección ou a función da empresa que se beneficie da solución se atopen cun coñecemento xenérico da solución a adoptar: sabe o que quere, non como dicilo de forma clara e explícita. Isto tamén o é útil apoio especializado no sector das TI, se está dirixido por bos analistas funcionais que poñen en práctica as habilidades adecuadas.
Aquí entón algunhas preguntas que lle fará o equipo: cal é a lista detallada de requisitos? Está claro cada punto para todo o equipo que elaborou a lista de verificación? Quen vai levar a cabo a negociación ten presente o seu mandato? E o propio mandato é específico e detallado ou ten lagoas? Unha boa estratexia a adoptar podería ser o método Scrum: quen participa no proxecto conta unha historia para que a exposición, de tipo discursivo, favoreza defición dos conceptos a empregar para o traballo.
Moitas veces as solucións empresariais no mercado non ten todas as funcións requiridas polo comprador. Os xestores da empresa saben isto desde o principio. Por esta razón, unha vez elaborada a lista de verificación, procedemos a establecer un índice de prioridade: toda empresa, unha vez establecidos os obxectivos, ten a súa.
"Moitas veces as solucións empresariais no mercadonon ten todas as funcións requiridas polo comprador. Os xestores da empresa saben isto desde o principio. Por esta razón, unha vez elaborada a lista de verificación, procedemos a establecer un índice de prioridade"
Algúns suxiren asociarse a cada requisito unha puntuación diferente de importancia: a puntuación global de cada solución examinada será a suma dos actuais requisitos e a súa importancia relativa. É un consello de sentido común, sempre que non sexas demasiado esquemático na avaliación final: é natural que na atribución dun clasificación Hai tamén factores externos ao software, máis que nada relacionados co provedor. Verémolos nun post posterior.
Para avaliar o intrínseco calidade do software é necesario establecer algúns métricas obxectivas (polo tanto máis alá dos requisitos funcionais, puramente subxectivos, requiridos pola empresa).
Non saber que variables para medir o produto significa non ser capaz de tomar conciencia do seu valor. De novo, queremos recompilar unha lista primeiro para examinar as solucións individuais: usaremos como medidor no momento da selección real.
Hai unha ampla literatura sobre o tema: de feito, simplemente escribe un motor de busca "Calidade do software" para descubrir publicacións e libros sobre o tema. Un punto de partida útil é a voz Wikipedia, que enumera un conxunto de parámetros externo (é dicir, sobre a calidade percibida polo usuario), para avaliar a calidade da solución a adquirir. Entre estes: corrección, fiabilidade, robustez, eficiencia. Pero tamén interiorverificable por un equipo de desenvolvedores: mantemento, reutilización, modularidade son algúns dos exemplos listados.
Tamén neste caso o equipo decide un índice de prioridade para os diversos parámetros: por exemplo a dirección da empresa, que ten a visión estratéxica do proxecto, pode atribuír importancia secundaria á reutilización do software. E, por suposto, nesta fase de selección de software, é bo saber a opinión do función de calidade da empresa (onde está presente).
É unha variable fundamental: antes de iniciar unha negociación, debes ter presente orzamento total do que ten dispoñible adquisición de software (tanto para o propio software como polos custos de hora-man necesarios para a actividade de selección). Para establecer unha suma realista, algúns xa teñen un punto de referencia das solucións adquiridas anteriormente pola empresa, outras confían no boca a boca entre compañeiros do mesmo sector (ou do mesmo grupo industrial). A comprobación do gasto anteriormente en solucións similares facilita o proceso de selección do software.
"Debe ter presente o orzamento total que ten dispoñible para o adquisición de software: comprobe canto se gastou anteriormente por solucións similares facilita de feito o proceso de selección de software "
Por suposto, o prezo dun software a nivel empresarial é consecuencia directa non só da súa calidade intrínseca, senón tamén do traballo realizado polo provedor para deseñalo e desenvolvelo: para amortizar os custos, hai formas flexibles de adquisición (veremos no punto 6).
Nunca haberá que falar sobre iso: todas as empresas están a tratar unha cantidade cada vez maior de datos relacionado coa súa empresa e os seus clientes. Ao mesmo tempo, sabemos que nos últimos anos aumentou o número de persoas ataques cibernéticos nas bases de datos da empresa. A protección da súa información é polo tanto unha responsabilidade directa e inevitable dos que a xestionan.
Unha das tarefas de quen leva a cabo a negociación será, polo tanto, coñecer as proteccións postas en marcha polo provedor. Mentres tanto, un coñecemento básico de riscos e solucións non pode prexudicar: Xerente do departamento TIC poderá informar os contactos da súa compañía sobre os dous aspectos.
Decida se prefires unha solución na nube (en infraestruturas remotas) ou premisa (instalado nos servidores da empresa) non é simplemente un problema: o orzamento e o tipo de xestión de datos teñen un impacto directo sobre eles como se administra o software.
Para moitos xestores, un solución na premisa aínda está asociado a unha percepción de estabilidade e control: non obstante, os investimentos máis substanciais deben ser considerados. Por outra banda, a nube é máis flexible e menos caro en termos de prezo, pero require que o provedor dea maiores garantías en termos de seguridade de datos e rendemento da canle (é dicir, velocidade de transmisión e execución do programa).
A forma na que se asumen os custos tamén cambia: o prezo na premisa baséase normalmente nun pago de licenzas, custos de personalización, configuración inicial, custos de mantemento posteriores, etc. A nube é un modelo pagar por uso: maior frutificación, maior custo. Normalmente, na modalidade de nube, todos os gastos que supoñen o custo transfórmanse nunha taxa que os resume, normalmente máis baixos (en comparación cun compromiso contractual plurianual, a miúdo de tres a cinco anos).
Pode parecer un paradoxo, pero só é aparentemente: unha boa lista de verificación das expectativas que formulamos sobre a nova solución ... non fai caso unha análise do software que cómpre cambiar. Por suposto, non nos estamos a referir á situación dunha primeira instalación.
"Non se ignora unha boa lista de verificación das expectativas que realizamos sobre a nova solución ... unha análise do software que cómpre cambiar"
En primeiro lugar, o propósito é indicar o debilidades: son as peculiaridades que nos levaron a buscar un produto diferente. Incluso as idades do software e o tratamento agresivo do mesmo poden resultar ser unha xogada incorrecta.
Non obstante, é posible que tamén teñamos que anotar algúns puntos fortes: de feito, non se di que a xestión do proceso coa antiga solución fose incompleta en todos os aspectos.
Tamén durante esta análise é útil facer un traballo compartido: coñecementos funcionais e coñecementos técnicos van da man e ambos contribúen a unha avaliación máis concreta da calidade do software. Incluso o de cambiar!
Persoalmente, creo que cando o software xa non é o adecuado é que non é culpa dos que fixeron a elección no seu momento. simplemente o mercado cambiou e que o software non responde ás novas necesidades empresariais. É por iso que a última orientación está cada vez máis cara a refactoring aplicacións continuas.
autor Paolo Ravalli
Google DeepMind presenta unha versión mellorada do seu modelo de intelixencia artificial. O novo modelo mellorado ofrece non só...
Laravel, famoso pola súa sintaxe elegante e poderosas características, tamén proporciona unha base sólida para a arquitectura modular. Alí…
Cisco e Splunk están axudando aos clientes a acelerar a súa viaxe ao Centro de Operacións de Seguridade (SOC) do futuro con...
O ransomware dominou as noticias nos últimos dous anos. A maioría da xente é ben consciente de que os ataques...
Realizouse unha operación de oftalmoplastia co visor comercial Apple Vision Pro no Policlínico de Catania...
O desenvolvemento da motricidade fina a través da cor prepara aos nenos para habilidades máis complexas como escribir. Para colorear…
O sector naval é unha verdadeira potencia económica mundial, que navega cara a un mercado de 150 millóns...
O pasado luns, o Financial Times anunciou un acordo con OpenAI. FT licencia o seu xornalismo de clase mundial...
