Los 8 mejores programas de servidor SFTP
Comparamos 8 implementaciones de servidor SFTP en un entorno de prueba controlado, centrándonos en el rendimiento de transferencia, la concurrencia, la sobrecarga de conexión, las cargas de archivos pequeños, la eficiencia de recursos y la experiencia operativa.
Si ya usa SFTP pero desea un enfoque de transferencia de archivos más preparado para la empresa, considere las soluciones MFT.
Resultados del benchmark de software de servidor SFTP
Rendimiento de transferencia
Coste operativo
Nota: Las puntuaciones más bajas indican un mejor rendimiento.
Lea la metodología para conocer nuestro entorno de prueba y los procesos de puntuación.
SFTPGo
SFTPGo es un servidor SFTP basado en Go distribuido como un binario independiente, con configuración disponible a través de JSON, variables de entorno, una interfaz web de administración y una API REST. Admite almacenamiento local, S3, Google Cloud Storage y backends de Azure Blob, e incluye características operativas como cuotas, reglas de eventos, autenticación de dos factores y métricas de Prometheus.
Figura 1: Ejemplo de inicio de sesión de SFTPGo.
Requerió una configuración mínima durante el benchmark. El principal problema fue un límite de conexiones por host predeterminado que rechazaba escrituras durante la prueba de archivos pequeños, pero desactivar ese límite resolvió el problema.
Una vez configurado, SFTPGo combinó un alto rendimiento de transferencia con la latencia de handshake más baja del grupo probado (25 ms en p50, menos de la mitad del siguiente servidor más rápido) y un bajo consumo de memoria por sesión (0.091 MB, aproximadamente 145× por debajo de OpenSSH). Su rendimiento multi-stream también escaló bien sin adoptar un model de proceso por conexión. Esa combinación lo convirtió en el resultado de propósito general más sólido de este benchmark.
Figura 2: Panel de administración de SFTPGo.
HPN-SSH
HPN-SSH es un derivado de OpenSSH orientado al rendimiento. Se instala junto con los binarios OpenSSH del sistema y conserva esencialmente el mismo model de configuración, añadiendo un comportamiento específico de HPN destinado principalmente a redes de alto ancho de banda y alta latencia. Para los administradores familiarizados con OpenSSH, las diferencias operativas son pequeñas.
El paquete inició automáticamente un servicio hpnssh.service durante la instalación, que ocupó el puerto asignado a la instancia de benchmark de OpenSSH hasta que el servicio se detuvo y enmascaró. Aparte de ese conflicto, se comportó de manera similar a OpenSSH.
Ofreció el mayor resultado de carga de un solo flujo (167.4 MB/s, aunque MINA con 166.9 MB/s y SFTPGo con 165.3 MB/s terminaron dentro del 1,3 %) y el arranque de proceso más rápido del benchmark (0.88 s), pero heredó el model de memoria de fork por conexión de OpenSSH. Bajo el límite de memoria impuesto de 6 GB, falló cuando la prueba de sesiones concurrentes alcanzó 300 conexiones.
El benchmark se ejecutó íntegramente sobre loopback, por lo que no prueba el entorno en el que HPN-SSH está específicamente diseñado para destacar. La latencia de red casi nula elimina la mayor parte de la restricción del producto ancho de banda-retardo a la que apuntan sus modificaciones de ventana más grande. Por lo tanto, su ventaja en WAN queda fuera del alcance de estos resultados.
Apache MINA SSHD
Apache MINA SSHD se diferencia de los demás porque es una biblioteca Java, a diferencia de un servidor SFTP listo para ejecutar. Para el benchmark, tuvimos que escribir un servidor usando los componentes sshd-core y sshd-sftp y luego compilarlo como un JAR independiente con Maven. La aplicación controla las claves de host, la autenticación, el soporte SFTP y la configuración de cifrado, en lugar de un archivo de configuración de servidor convencional.
Esto implicó más trabajo de configuración que cualquier demonio empaquetado. La compilación requirió un objetivo de compilador de Java moderno explícito, y la autenticación Ed25519 necesitó una dependencia adicional. El autenticador estándar de claves autorizadas también rechazó el archivo de claves del benchmark debido a sus comprobaciones de permisos, por lo que el servidor de prueba utilizó una ruta de comparación de claves personalizada.
Sin embargo, una vez en funcionamiento, MINA se comportó bien: produjo el resultado de descarga más alto (172.4 MB/s), un bajo consumo de memoria por sesión y la segunda mejor eficiencia de CPU medida en la prueba de eficiencia de recursos (132,8 % por Gbps, detrás del 119,4 % de OpenSSH). La principal penalización en tiempo de ejecución fue el tiempo de arranque de la JVM (3.39 s hasta la primera conexión). Por lo tanto, es un componente de implementación atractivo para aplicaciones que necesitan un endpoint SFTP integrado, pero no un sustituto directo de un producto SFTP orientado al administrador.
OpenSSH
OpenSSH sirvió como implementación de referencia. Estaba presente en el sistema de prueba Ubuntu y no requirió instalación adicional del servidor. SFTP se expone mediante internal-sftp, mientras que los usuarios, las claves públicas, las reglas de chroot y los controles de acceso utilizan los mecanismos estándar de cuentas de OpenSSH y sshd_config.
Los problemas operativos fueron problemas conocidos de OpenSSH, no inestabilidad del subsistema SFTP en sí. Los propietarios o permisos incorrectos activaron StrictModes, y el servicio systemd de HPN-SSH inicialmente ocupó el puerto del benchmark. Después de eliminar ese conflicto, el servidor se ejecutó de manera constante.
OpenSSH gestionó la carga de archivos pequeños mejor que cualquier otra implementación probada (4.466 archivos por segundo, un 42 % por delante del siguiente servidor más rápido) y registró el menor coste de CPU por unidad de rendimiento, con 119,4 % por Gbps, pero su arquitectura de fork por conexión utilizó comparativamente más memoria por sesión activa (13.283 MB).
Sus resultados de rendimiento en archivos grandes requieren una matización adicional: esta instancia del benchmark escribió en el directorio de inicio del usuario del sistema en disco, mientras que los demás servidores probados usaron tmpfs. Por lo tanto, sus valores absolutos de rendimiento T1 y T2, así como la cifra de CPU por Gbps normalizada con respecto a ellos, no deben considerarse directamente equivalentes al resto de los participantes.
ProFTPD
ProFTPD proporciona SFTP a través de mod_sftp. No trata SFTP como su protocolo principal. Su sistema de configuración estilo Apache es maduro y flexible, y el servidor en su conjunto puede combinar FTP, FTPS y SFTP con autenticación SQL o LDAP y controles de acceso granulares.
También fue el servidor más problemático de configurar durante este benchmark. mod_sftp tuvo que cargarse explícitamente, la política de sobrescritura predeterminada bloqueaba las subidas, la validación del shell afectó al usuario del benchmark y un proceso ProFTPD obsoleto impidió que una instancia posterior se enlazara a su puerto.
Su ruta SFTP produjo el menor rendimiento de descarga (77.2 MB/s) y, con diferencia, la mayor latencia de handshake entre los servidores medidos (423 ms en p50, 3.6× el siguiente más lento). La excepción fue el escalado de flujos paralelos: el rendimiento agregado aumentó sustancialmente a medida que aumentaba la concurrencia, alcanzando 3.51× el de un solo flujo con cuatro flujos, lo que dio a ProFTPD la mayor relación de escalado en esa prueba. Estos resultados tienen más sentido en entornos que necesitan sus capacidades multiprotocolo maduras que en despliegues que eligen un servidor específicamente por su rendimiento SFTP.
SFTPPlus
SFTPPlus es una plataforma comercial de transferencia de archivos gestionada construida sobre Python y Twisted. Se distribuye con su propio runtime de Python y utiliza un formato de configuración legible basado en INI. Además de SFTP, admite FTPS, HTTPS y WebDAV, junto con funciones administrativas, de automatización, auditoría, integración de directorios y alta disponibilidad que se esperan de un producto MFT.
La instalación en sí fue sencilla, pero la gestión de procesos introdujo varios problemas específicos del benchmark. Iniciar como root requirió una configuración de cuenta explícita, el lanzador en primer plano dependía de ejecutarse desde el directorio de instalación y el nombre del proceso en tiempo de ejecución difería de lo que esperaba la lógica de monitorización inicial.
El rendimiento reflejó prioridades diferentes a las de los servidores orientados al rendimiento: SFTPPlus tuvo un consumo de memoria incremental por sesión excepcionalmente bajo (0.028 MB, el más bajo medido) y una buena latencia de establecimiento de conexión (52 ms en p50), pero cargas de archivos grandes relativamente lentas (41.8 MB/s), gestión de archivos pequeños (244 archivos por segundo) y arranque de proceso (7.49 s, más del doble que el siguiente servidor más lento).
Wing FTP Server
Wing FTP Server es un servidor nativo comercial con una interfaz de administración basada en web y soporte para FTP, FTPS, SFTP, HTTP y HTTPS. La configuración se organiza en torno a dominios y usuarios, con la interfaz web como principal vía de gestión; también están disponibles la configuración XML y una interfaz de consola basada en Lua.
Figura 3: Panel de administración de Wing FTP.
La GUI resultó más fácil de abordar que la mayoría de las configuraciones basadas en texto, pero varios comportamientos complicaron la automatización. La llamada de creación de dominios en Lua falló repetidamente sin un error útil; rechazó una clave de cliente Ed25519. Al mismo tiempo, RSA-3072 funcionó, y un mapeo de directorio de inicio creado a través de la interfaz gráfica no persistió hasta que lo añadimos manualmente.
El rendimiento medido fue notablemente asimétrico: las descargas fueron considerablemente más rápidas que las subidas (129.7 MB/s frente a 34 MB/s, una brecha de 3.8× y la cifra de subida más baja del benchmark), el procesamiento de archivos pequeños fue el más lento del grupo (90 archivos por segundo, frente a 244 del siguiente más lento), y el consumo de CPU en relación con el rendimiento alcanzado fue alto (433,7 % por Gbps, casi el doble que el siguiente servidor más alto). El uso de memoria por sesión, por el contrario, se mantuvo bajo (0.107 MB) porque el servidor utiliza una arquitectura de hilos en lugar de fork por conexión.
Figura 4: Editor de usuarios de Wing FTP.
CrushFTP
CrushFTP 11.5.2 se instaló correctamente y aceptó conexiones SFTP mediante autenticación de clave pública Ed25519, pero no pudo incluirse en la comparación de rendimiento. Cada subida falló con una respuesta del servidor 550 openFile error:Denied! a pesar de tener permisos de escritura en el sistema de archivos y una configuración de usuario válida.
Figura 5: Ejemplo de inicio de sesión de CrushFTP.
La investigación señaló el estado de registro instalado como la causa probable, porque las escrituras se denegaban de forma global y no en una ruta específica, pero no lo verificamos de manera concluyente. No intentamos eludir ni falsificar la licencia.
Se requiere una licencia de prueba o de producción válida antes de poder probar CrushFTP en las mismas condiciones que los demás servidores, por lo que no podemos extraer ninguna conclusión de rendimiento de esta ejecución.
Figura 6: Interfaz web de CrushFTP.
Metodología del benchmark de software de servidor SFTP
Objetivo de la prueba
El benchmark compara el comportamiento del lado del servidor de las implementaciones SFTP en condiciones controladas. Restringimos o aislamos el almacenamiento, la latencia de red, el rendimiento del cliente, la CPU disponible y la memoria cuando fue posible, para que las diferencias entre las implementaciones de servidor siguieran siendo visibles.
Esto hace deliberadamente que el benchmark sea más limitado que una prueba de transferencia de producción de extremo a extremo. En concreto, el loopback y el almacenamiento respaldado por memoria pretendían poner de manifiesto el procesamiento del protocolo, el cifrado, la concurrencia, la arquitectura de procesos y los costes de gestión de conexiones, en lugar del rendimiento de la WAN o del sistema de almacenamiento.
Entorno de prueba
Separar la afinidad de CPU del cliente y del servidor redujo la contención directa de CPU entre el generador de carga y el servidor. El límite de memoria de 6 GB proporcionó un tope consistente para la prueba de sesiones concurrentes e hizo visible el coste de los diseños de proceso por conexión. tmpfs eliminó el rendimiento normal del disco en la mayoría de las pruebas, mientras que loopback eliminó la variabilidad de la red física.
Antes de probar las implementaciones SFTP, medimos de forma independiente los límites aproximados del host. AES-128-GCM alcanzó 2.737 MB/s, ChaCha20-Poly1305 1.430 MB/s, las escrituras secuenciales en almacenamiento 2.687 MB/s, las escrituras aleatorias aproximadamente 263.000 IOPS, y las redes loopback 1.889 MB/s. Por lo tanto, los resultados SFTP sustancialmente por debajo de estos valores pueden interpretarse como limitados principalmente por el servidor y la ruta del protocolo, y no por esos subsistemas de hardware individuales.
Implementación del cliente
El comando estándar sftp de OpenSSH no se utilizó como generador principal de transferencias porque, en este entorno, su comportamiento de un solo flujo se estancó en aproximadamente 90 MB/s. En ese punto, el benchmark habría estado midiendo una limitación del cliente en lugar de diferencias entre servidores.
En su lugar, las pruebas utilizaron un cliente Go personalizado basado en github.com/pkg/sftp. Realiza lecturas y escrituras concurrentes para que el servidor se convierta en el lado limitante de la transferencia. El tamaño del paquete SFTP se mantuvo en 32 KB, coincidiendo con los valores predeterminados normales que utilizan OpenSSH y pkg/sftp. Probamos una configuración de 256 KB durante el desarrollo, pero provocó fallos en las conexiones OpenSSH, por lo que no la utilizamos.
T1: Rendimiento de un solo flujo
T1 midió la ruta básica de transferencia de archivos grandes. Subimos un único archivo de 3 GB y lo descargamos, registrando cada dirección de forma independiente. Repetimos cada medición tres veces y conservamos el resultado de la mediana. Las cachés del sistema de archivos se eliminaron entre repeticiones.
Esta prueba no pretendía estimar el rendimiento real en una WAN. Con el cliente y el servidor en la misma máquina, ofrece una visión controlada de la rapidez con la que cada servidor puede procesar un flujo SFTP sostenido cuando se han eliminado las limitaciones de red y, en la mayoría de las implementaciones, las del disco físico.
T1b: Comparación de cifrado
T1b repitió la carga de descarga forzando AES-128-GCM o ChaCha20-Poly1305 desde el lado del cliente. Esto puso de manifiesto diferencias en el soporte de cifrado y en cómo cada implementación interactúa con las capacidades criptográficas de la CPU del host.
Registramos los cifrados no compatibles o las transferencias fallidas como resultados faltantes. El host admite aceleración AES, por lo que el entorno de prueba favorece de forma natural las implementaciones eficientes de AES-GCM, pero los resultados siguieron dependiendo de cada implementación.
T2: Escalado de flujos paralelos
T2 midió cómo cambiaba el rendimiento agregado cuando la misma carga de trabajo se dividía entre uno, dos y cuatro flujos simultáneos. El total de datos transferidos se mantuvo fijo en 3 GB; por lo tanto, aumentar el número de flujos cambió la concurrencia.
La relación de cuatro flujos a un flujo se utilizó como principal indicador de escalado. Un resultado cercano a uno sugiere que las conexiones adicionales apenas aumentan el rendimiento, mientras que una relación mayor indica que el servidor puede aprovechar capacidad de ejecución adicional bajo carga paralela. Dado que la carga útil total era fija, la prueba hace hincapié en la concurrencia y el uso de CPU en lugar de premiar una carga de trabajo mayor.
T3: Carga de archivos pequeños
Las transferencias secuenciales grandes no representan cargas de trabajo dominadas por operaciones del sistema de archivos y del protocolo. Por ello, T3 subió 20.000 archivos de 4 KB cada uno y midió los archivos completados por segundo.
Con este tamaño, el ancho de banda de transferencia masiva no es el coste principal. Cada archivo requiere una secuencia de operaciones SFTP y trabajo de metadatos del sistema de archivos, lo que hace que la prueba sea sensible a la sobrecarga de apertura, creación, cierre y gestión de solicitudes. Complementa a T1 en lugar de servir como otra medición de rendimiento.
T4: Sobrecarga de conexión y autenticación
T4 realizó 500 sesiones secuenciales. Cada iteración establecía una conexión, se autenticaba mediante una clave pública y se desconectaba sin ejecutar una transferencia sostenida.
Registramos la latencia de conexión como valores p50, p95 y p99, junto con los inicios de sesión completados por segundo. Esto aísla el establecimiento de sesiones SSH/SFTP y hace visibles las diferencias arquitectónicas, incluido el coste adicional de gestión de procesos asociado a los servidores que hacen fork por cada conexión.
Probamos la autenticación de clave pública. Dejamos fuera del benchmark actual los mecanismos de autenticación por contraseña, interactiva por teclado, por certificado, GSSAPI/Kerberos y de múltiples factores, por lo que T4 no debe generalizarse a esos mecanismos de autenticación.
T5: Sesiones concurrentes y escalado de memoria
T5 aumentó progresivamente el número de sesiones simultáneas de 50 a 500 y registró tanto el mayor número de conexiones sostenibles como la memoria residente consumida por sesión. Todos los servidores se ejecutaron bajo el mismo límite de memoria de 6 GB.
Esta prueba fue especialmente útil para distinguir arquitecturas de servidor. Las implementaciones derivadas de OpenSSH y otras basadas en fork por conexión crean una sobrecarga de proceso por sesión considerable. Por el contrario, las implementaciones basadas en eventos, en goroutines o en hilos pueden compartir considerablemente más estado entre conexiones. Cuando un servidor fallaba antes de alcanzar el máximo de la rampa, el punto de fallo se conservaba como parte del resultado, no como una extrapolación de una capacidad mayor.
El límite de 500 sesiones es una limitación de este entorno de prueba. No es una afirmación sobre la capacidad máxima de los servidores que lo completaron. Medir su límite superior real requeriría un host más grande y una rampa de conexiones considerablemente mayor.
T6: Eficiencia de recursos
T6 midió el uso de CPU y memoria mientras había una transferencia continua activa. El uso de CPU y el RSS se muestrearon en todo el árbol de procesos del servidor cada 0,5 segundos, en lugar de supervisar únicamente el proceso padre.
La eficiencia de CPU se normalizó como porcentaje de CPU por Gbps de rendimiento alcanzado. Esto proporciona contexto: un bajo consumo de CPU es útil si el servidor también transfiere datos a un ritmo significativo.
T7: Arranque en frío
T7 midió el tiempo transcurrido desde el inicio del proceso del servidor hasta que aceptó su primera conexión. Esto captura la sobrecarga de arranque, que es en gran medida irrelevante para demonios de larga duración, pero puede importar en entornos de prueba desechables, contenedores, servicios de corta duración y flujos de trabajo de despliegue automatizados.
La medición también pone de manifiesto diferencias en tiempo de ejecución que en su mayoría desaparecen una vez que el proceso está caliente, especialmente entre demonios nativos pequeños y aplicaciones que deben inicializar una JVM o un runtime basado en Python antes de aceptar conexiones.
Interpretación de los resultados
Los valores faltantes indican funcionalidad no compatible o una medición que no pudimos completar; no inferimos valores de sustitución.
El entorno loopback es especialmente importante al interpretar T1 y T2. Las clasificaciones relativas y el comportamiento de escalado son útiles en este host controlado, pero no trate las cifras absolutas de MB/s como predicciones para una red real. La latencia, la pérdida de paquetes, el producto ancho de banda-retardo, el almacenamiento remoto y el comportamiento del cliente pueden cambiar sustancialmente el resultado.
OpenSSH también requiere una matización específica: su cuenta del benchmark escribió en un directorio de inicio respaldado por disco en lugar del tmpfs utilizado por las demás implementaciones. Por lo tanto, sus cifras absolutas de T1 y T2 no son estrictamente comparables con las de los demás servidores, aunque las mediciones siguen siendo útiles para comprender su comportamiento en la configuración probada.
Soluciones de transferencia de archivos gestionadas para SFTP
Si desea más funciones administrativas y un uso más sencillo, también puede elegir soluciones de transferencia de archivos gestionadas:
JSCAPE
JSCAPE ofrece una plataforma de transferencia de archivos gestionada con capacidades de servidor SFTP, lo que permite intercambios de archivos seguros y cifrados a través de redes. También admite el protocolo OFTP2 para la transmisión segura de datos en la industria automotriz y otras industrias.
Elegir JSCAPE como SFTPStonebranch
La función Secure File Transfer Protocol (SFTP) de Stonebranch forma parte de su solución Managed File Transfer (MFT) y proporciona transferencias de datos seguras, fiables y automatizadas. Compatible con diversos entornos de TI, incluidos mainframes, plataformas en la nube y sistemas híbridos, la función de software de servidor SFTP garantiza el cifrado y el cumplimiento de los estándares de seguridad de la industria, lo que la hace adecuada tanto para intercambios de archivos internos como externos.
Explorar StonebranchDiplomat MFT de Coviant Software
Diplomat MFT de Coviant Software es una plataforma de transferencia de archivos gestionada autoalojada construida en torno a SFTP. Aloja su propio servidor SFTP para socios entrantes, se conecta a los servidores SFTP de los socios y aplica cifrado OpenPGP por transacción.
El Edge Gateway se sitúa en la DMZ y acepta las conexiones de los socios, mientras que el servidor Diplomat que ejecuta los flujos de trabajo permanece en la red interna. No se almacenan credenciales ni archivos en el perímetro, y el firewall interno no necesita reglas de entrada. Se despliega principalmente en sectores regulados como la atención sanitaria, los servicios financieros, el gobierno, el comercio minorista y la fabricación.
La versión 9.5.1 (octubre de 2026) añade control de algoritmos SSH tanto en el lado del servidor como en el del socio. Los administradores pueden habilitar, deshabilitar y reordenar los algoritmos de intercambio de claves, firma, cifrado, HMAC y compresión, y los algoritmos obsoletos están deshabilitados de forma predeterminada.
Los clientes SFTP entrantes se comprueban contra la reputación de IP de Threat Intelligence. Una nueva lista de anulación admite socios verificados en direcciones de nube compartidas sin desactivar el bloqueo. La opción TOTP añadida para los usuarios del Web Transfer Portal en la misma versión no se aplica a SFTP, que sigue dependiendo de la autenticación basada en claves y de las reglas de acceso por IP.
Explorar Diplomat MFTCerberus FTP Server
Cerberus FTP Server es una solución basada en Windows diseñada para configuraciones on-premise o en la nube. Incluye integración AD/LDAP, SSO, transferencias de cliente web y cumplimiento de estándares de cifrado como FIPS 140-2. Entre las características esenciales se incluyen el escaneo automatizado, la automatización basada en eventos y el soporte de cumplimiento de HIPAA.
Elegir CerberusGoAnywhere MFT
GoAnywhere MFT ofrece una solución SFTP segura para transferencias de archivos, con énfasis en el cifrado y el cumplimiento. Su objetivo es garantizar la integridad y confidencialidad de los datos, con funciones de gestión de claves, autenticación y registro, dirigido a organizaciones que priorizan intercambios de datos seguros y regulados.
Lecturas adicionales
- Las 10 mejores soluciones de transferencia de archivos gestionadas (MFT)
- Las 6 mejores soluciones de software AS2: selecciones de 400+ reseñas
- Axway Managed File Transfer: aspectos clave a considerar
Añadir como fuente preferidaCita este benchmark
Elige el formato que se ajuste al lugar donde vas a publicar. Pegar la versión con enlace en tu CMS conserva el enlace de retroceso.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Ermut, Sıla},
title = {{Los 8 mejores programas de servidor SFTP}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/sftp-server-software}},
note = {AIMultiple. Recuperado el 27 de octubre de 2026}
}Resultados y marcas de tiempo de 72 puntos de datos. Descargue los datos resumidos que se muestran en los gráficos y las tablas de este artículo como un archivo ZIP que contiene 10 archivos CSV y un README.
¿Quieres los datos granulares que hay detrás? Únete a Premium
Registro de cambios
11 actualizacionesSe añadió una sección de metodología de benchmark sobre ocho servidores SFTP.
Se reemplazó la sección de Files.com por una nueva sección sobre Diplomat MFT de Coviant Software.
Se añadieron Stonebranch y Files.com a la lista de soluciones de servidor SFTP.
El trabajo de Cem en AIMultiple ha sido citado por publicaciones líderes mundiales como Business Insider, Forbes, Morning Brew y Washington Post, empresas globales como Deloitte y HPE, ONG como World Economic Forum y organizaciones supranacionales como European Commission. [1], [2], [3], [4], [5]
A lo largo de su carrera, Cem trabajó como consultor tecnológico, comprador de tecnología y emprendedor tecnológico. Asesoró a empresas en sus decisiones tecnológicas en McKinsey & Company y Altman Solon durante más de una década. También publicó un informe de McKinsey sobre digitalización.
Dirigió la estrategia tecnológica y las adquisiciones de una empresa de telecomunicaciones reportando al CEO. También lideró el crecimiento comercial de la empresa de deep tech Hypatos, que alcanzó unos ingresos recurrentes anuales de 7 dígitos y una valoración de 9 dígitos desde 0 en 2 años. El trabajo de Cem en Hypatos fue cubierto por publicaciones tecnológicas líderes como TechCrunch y Business Insider.
Cem participa habitualmente en conferencias internacionales de tecnología. Se graduó en Bogazici University como ingeniero informático y tiene un MBA de Columbia Business School.
Anteriormente trabajó como reclutadora en empresas de gestión de proyectos y consultoría. Sıla tiene un máster en Psicología Social y una licenciatura en Relaciones Internacionales.
Sé el primero en comentar
Tu dirección de correo electrónico no será publicada. Todos los campos son obligatorios. Los comentarios se dejan en su idioma original.