Skip to main content

evaluate-a-vendor

Compare vendors against weighted requirements, verified evidence, operating risk, and total cost. Use when selecting, renewing, replacing, or piloting a business supplier.

Datos de origen

Repositorio
protosphinx/sphinxstack
Última actividad en el origen
29 de julio de 2026 a las 13:55
Idioma detectado de SKILL.md
inglés
Estrellas
3
Forks
0

Opciones de instalación

De forma predeterminada está seleccionado el prompt que primero revisa el origen. Puedes cambiar a un comando directo o descargar una copia local.

Revisa los archivos de origen

Lee SKILL.md y los archivos complementarios que muestra SkillsMP antes de decidir si quieres instalarlo.

Explorador de archivos
2 archivos

Mostrando SKILL.md

SKILL.md
Instrucciones de origen · Vista previa de solo lectura
name
evaluate-a-vendor
category
data
description
Compare vendors against weighted requirements, verified evidence, operating risk, and total cost. Use when selecting, renewing, replacing, or piloting a business supplier.
# evaluate-a-vendor Make the decision reproducible. Keep vendor claims, verified facts, assumptions, and stakeholder preferences separate. ## When to use - Use for software, services, equipment, logistics, professional services, and other operational suppliers. - Add security, legal, finance, privacy, accessibility, or domain review when their risks are material. ## Procedure 1. Define the business outcome, users, constraints, decision owner, budget boundary, and implementation deadline. 2. Turn needs into must-have gates, weighted criteria, and explicit non-goals before reviewing vendors. 3. Build a common evidence request covering functionality, service, implementation, support, security, data, exit, references, and pricing. 4. Record each response as verified, vendor-asserted, assumed, not applicable, or unknown. 5. Test critical workflows with representative data and acceptance criteria. 6. Model total cost including implementation, migration, usage, support, training, integration, growth, renewal, and exit. 7. Assess concentration, continuity, lock-in, subcontractors, incident history, capacity, and dependency risk. 8. Check references with comparable scale and use cases. 9. Score consistently, run sensitivity analysis on weights and uncertain costs, and document exceptions. 10. Recommend select, pilot, negotiate, defer, or reject with conditions and an evidence trail. ## Failure plan - Do not convert a polished demo or roadmap promise into verified capability. - If a must-have fails, do not hide it inside a weighted total. - Keep confidential bids access-controlled and follow procurement conflict rules. - If no vendor passes, report the gap instead of selecting the least-bad option silently. ## Done - Requirements, evidence status, tests, cost, risk, references, and scoring are auditable - The outcome remains understandable under reasonable weight changes - Unknowns, exceptions, owners, and exit conditions are explicit
Ver en GitHub