I 8 migliori software per server SFTP
Abbiamo confrontato 8 implementazioni di server SFTP in un ambiente di test controllato, concentrandoci su prestazioni di trasferimento, concorrenza, overhead di connessione, carichi di lavoro con file piccoli, efficienza delle risorse ed esperienza operativa.
Se utilizzi già SFTP ma desideri un approccio al trasferimento file più pronto per l'azienda, considera le soluzioni MFT.
Risultati del benchmark del software per server SFTP
Prestazioni di trasferimento
Costo operativo
Nota: punteggi più bassi indicano prestazioni migliori.
Leggi la metodologia per conoscere il nostro ambiente di test e i processi di valutazione.
SFTPGo
SFTPGo è un server SFTP basato su Go distribuito come binario autonomo, con configurazione disponibile tramite JSON, variabili d'ambiente, un'interfaccia di amministrazione web e una API REST. Supporta storage locale, S3, Google Cloud Storage e backend Azure Blob, e include funzionalità operative come quote, regole per eventi, autenticazione a due fattori e metriche Prometheus.
Figura 1: esempio di accesso SFTPGo.
Ha richiesto una configurazione minima durante il benchmark. Il problema principale è stato un limite di connessione predefinito per host che rifiutava le scritture durante il test con file piccoli, ma disabilitando tale limite il problema è stato risolto.
Una volta configurato, SFTPGo ha combinato elevate prestazioni di trasferimento con la latenza di handshake più bassa del gruppo testato (25 ms al p50, meno della metà del server successivo più veloce) e un basso consumo di memoria per sessione (0.091 MB, circa 145× inferiore a OpenSSH). Anche le sue prestazioni multi-stream si sono scalate bene senza adottare un modello process-per-connection. Questa combinazione lo ha reso il risultato general-purpose più forte di questo benchmark.
Figura 2: dashboard di amministrazione SFTPGo.
HPN-SSH
HPN-SSH è una derivata di OpenSSH orientata alle prestazioni. Si installa insieme ai binari OpenSSH di sistema e mantiene essenzialmente lo stesso modello di configurazione, aggiungendo un comportamento specifico HPN pensato principalmente per reti ad alta banda e alta latenza. Per gli amministratori che conoscono OpenSSH, le differenze operative sono minime.
Il pacchetto ha avviato automaticamente un servizio hpnssh.service durante l'installazione, che ha occupato la porta assegnata all'istanza OpenSSH del benchmark finché il servizio non è stato arrestato e mascherato. A parte questo conflitto, si è comportato in modo simile a OpenSSH.
Ha ottenuto il miglior risultato di upload single-stream (167.4 MB/s, sebbene MINA a 166.9 MB/s e SFTPGo a 165.3 MB/s abbiano chiuso entro l'1.3%) e l'avvio del processo più rapido del benchmark (0.88 s), ma ha ereditato il modello di memoria fork-per-connection di OpenSSH. Con il limite di memoria di 6 GB imposto, è fallito quando il test con sessioni concorrenti ha raggiunto 300 connessioni.
Il benchmark è stato eseguito interamente su loopback, quindi non testa l'ambiente in cui HPN-SSH è specificamente progettato per distinguersi. Una latenza di rete quasi nulla rimuove gran parte del vincolo banda-prodotto-di-ritardo a cui mirano le sue modifiche con finestre più grandi. Il suo vantaggio WAN rimane pertanto al di fuori dell'ambito di questi risultati.
Apache MINA SSHD
Apache MINA SSHD si distingue dagli altri perché è una libreria Java, a differenza di un server SFTP pronto all'uso. Per il benchmark, abbiamo dovuto scrivere un server utilizzando i componenti sshd-core e sshd-sftp e poi compilarlo come JAR autonomo con Maven. L'applicazione controlla chiavi host, autenticazione, supporto SFTP e configurazione dei cifrari, anziché un file di configurazione server convenzionale.
Ciò ha comportato più lavoro di configurazione rispetto a qualsiasi demone preconfezionato. La compilazione ha richiesto un target esplicito per un compilatore Java moderno e l'autenticazione Ed25519 necessitava di una dipendenza aggiuntiva. Anche l'autenticatore standard authorized-key ha rifiutato il file chiave del benchmark a causa dei controlli sui permessi, quindi il server di test ha utilizzato un percorso personalizzato di confronto delle chiavi.
Una volta in esecuzione, tuttavia, MINA ha ottenuto buoni risultati: ha prodotto il miglior risultato di download (172.4 MB/s), un basso consumo di memoria per sessione e la seconda migliore efficienza della CPU misurata nel test di efficienza delle risorse (132.8% per Gbps, dietro al 119.4% di OpenSSH). La principale penalità a runtime è stata il tempo di avvio della JVM (3.39 s alla prima connessione). È quindi un componente di implementazione interessante per applicazioni che hanno bisogno di un endpoint SFTP incorporato, ma non un sostituto diretto di un prodotto SFTP orientato all'amministratore.
OpenSSH
OpenSSH è servito come implementazione di riferimento. Era presente sul sistema di test Ubuntu e non ha richiesto alcuna installazione aggiuntiva del server. SFTP è esposto tramite internal-sftp, mentre utenti, chiavi pubbliche, regole chroot e controlli di accesso utilizzano i meccanismi standard degli account OpenSSH e sshd_config.
I problemi operativi erano problemi noti di OpenSSH, non instabilità del sottosistema SFTP stesso. Proprietà o permessi errati attivavano StrictModes e il servizio systemd di HPN-SSH inizialmente occupava la porta del benchmark. Dopo aver rimosso quel conflitto, il server è rimasto stabile.
OpenSSH ha gestito il carico di lavoro con file piccoli meglio di qualsiasi altra implementazione testata (4.466 file al secondo, 42% in più rispetto al server successivo più veloce) e ha registrato il costo CPU più basso per unità di throughput con 119.4% per Gbps, ma la sua architettura fork-per-connection ha utilizzato comparativamente più memoria per sessione attiva (13.283 MB).
I risultati di throughput su file di grandi dimensioni richiedono una precisazione aggiuntiva: questa istanza del benchmark ha scritto nella directory home dell'utente di sistema su disco, mentre gli altri server testati utilizzavano tmpfs. I valori assoluti di throughput T1 e T2 e il dato CPU-per-Gbps normalizzato rispetto a essi, pertanto, non dovrebbero essere considerati direttamente equivalenti al resto del gruppo.
ProFTPD
ProFTPD offre SFTP tramite mod_sftp. Non tratta SFTP come protocollo principale. Il suo sistema di configurazione in stile Apache è maturo e flessibile, e il server più ampio può combinare FTP, FTPS e SFTP con autenticazione SQL o LDAP e controlli di accesso granulari.
È stato anche il server più problematico da configurare durante questo benchmark. mod_sftp doveva essere caricato esplicitamente, la policy di sovrascrittura predefinita bloccava gli upload, la validazione della shell influiva sull'utente del benchmark e un processo ProFTPD residuo impediva a un'istanza successiva di eseguire il binding alla propria porta.
Il suo percorso SFTP ha prodotto il throughput di download più basso (77.2 MB/s) e di gran lunga la latenza di handshake più alta tra i server misurati (423 ms al p50, 3.6× il successivo più lento). L'eccezione è stata la scalabilità dei flussi paralleli: il throughput aggregato è aumentato sostanzialmente all'aumentare della concorrenza, raggiungendo 3.51× il single-stream a quattro flussi, conferendo a ProFTPD il rapporto di scalabilità più elevato in quel test. Questi risultati hanno più senso in ambienti che necessitano delle sue capacità multi-protocollo mature piuttosto che in implementazioni che scelgono un server specificamente per le prestazioni SFTP.
SFTPPlus
SFTPPlus è una piattaforma commerciale di managed file transfer basata su Python e Twisted. Viene distribuita con il proprio runtime Python e utilizza un formato di configurazione leggibile basato su INI. Oltre a SFTP, supporta FTPS, HTTPS e WebDAV, insieme a funzioni amministrative, di automazione, audit, integrazione con directory e alta disponibilità attese da un prodotto MFT.
L'installazione in sé è stata semplice, ma la gestione dei processi ha introdotto diversi problemi specifici del benchmark. L'avvio come root richiedeva un'impostazione esplicita dell'account, il launcher in primo piano dipendeva dall'esecuzione dalla directory di installazione e il nome del processo runtime differiva da quanto si aspettava la logica di monitoraggio iniziale.
Le prestazioni riflettevano priorità diverse rispetto ai server orientati al throughput: SFTPPlus ha mostrato un consumo di memoria incrementale per sessione eccezionalmente basso (0.028 MB, il più basso misurato) e una buona latenza di creazione della connessione (52 ms al p50), ma upload di file di grandi dimensioni relativamente lenti (41.8 MB/s), gestione dei file piccoli (244 file al secondo) e avvio del processo (7.49 s, più del doppio del server successivo più lento).
Wing FTP Server
Wing FTP Server è un server nativo commerciale con un'interfaccia di amministrazione web e supporto per FTP, FTPS, SFTP, HTTP e HTTPS. La configurazione è organizzata attorno a domini e utenti, con l'interfaccia web come percorso di gestione principale; sono disponibili anche la configurazione XML e un'interfaccia console basata su Lua.
Figura 3: dashboard di amministrazione Wing FTP.
La GUI è stata più facile da affrontare rispetto alla maggior parte delle configurazioni testuali, ma diversi comportamenti hanno complicato l'automazione. La chiamata Lua per la creazione del dominio falliva ripetutamente senza un errore utile; rifiutava una chiave client Ed25519. Allo stesso tempo, RSA-3072 funzionava, e una mappatura della directory home creata tramite la GUI non persisteva finché non l'abbiamo aggiunta manualmente.
Le prestazioni misurate erano notevolmente asimmetriche: i download erano considerevolmente più veloci degli upload (129.7 MB/s contro 34 MB/s, un divario di 3.8× e il dato di upload più basso del benchmark), l'elaborazione dei file piccoli era la più lenta del gruppo (90 file al secondo, contro 244 del successivo più lento), e il consumo di CPU rispetto al throughput raggiunto era elevato (433.7% per Gbps, quasi il doppio del server successivo più alto). L'uso di memoria per sessione, al contrario, è rimasto basso (0.107 MB) perché il server utilizza un'architettura threaded invece di fork-per-connection.
Figura 4: editor utenti Wing FTP.
CrushFTP
CrushFTP 11.5.2 è stato installato correttamente e ha accettato connessioni SFTP utilizzando l'autenticazione a chiave pubblica Ed25519, ma non è stato possibile includerlo nel confronto delle prestazioni. Ogni upload falliva con una risposta lato server 550 openFile error:Denied! nonostante permessi del filesystem scrivibili e una configurazione home utente valida.
Figura 5: esempio di accesso CrushFTP.
L'indagine ha indicato lo stato di registrazione installato come probabile causa, perché le scritture venivano negate globalmente anziché su un percorso specifico, ma non l'abbiamo verificato in modo definitivo. Non abbiamo tentato di aggirare o falsificare la licenza.
È necessaria una licenza di prova o di produzione valida prima che CrushFTP possa essere testato sulla stessa base degli altri server, quindi non possiamo trarre alcuna conclusione sulle prestazioni da questa esecuzione.
Figura 6: interfaccia web CrushFTP.
Metodologia del benchmark del software per server SFTP
Obiettivo del test
Il benchmark confronta il comportamento lato server delle implementazioni SFTP in condizioni controllate. Abbiamo limitato o isolato storage, latenza di rete, throughput del client, CPU disponibile e memoria, ove possibile, affinché le differenze tra le implementazioni server restassero visibili.
Ciò rende deliberatamente il benchmark più ristretto di un test di trasferimento di produzione end-to-end. In particolare, il loopback e lo storage supportato dalla memoria erano intesi a mettere in evidenza i costi di elaborazione del protocollo, crittografia, concorrenza, architettura di processo e gestione delle connessioni piuttosto che le prestazioni della WAN o del sistema di storage.
Ambiente di test
Separare l'affinità CPU del client e del server ha ridotto la contesa diretta della CPU tra il generatore di carico e il server. Il tetto di memoria di 6 GB ha fornito un limite coerente per il test con sessioni concorrenti e ha reso visibile il costo dei progetti process-per-connection. tmpfs ha rimosso il normale throughput del disco dalla maggior parte dei test, mentre il loopback ha eliminato la variabilità della rete fisica.
Prima di testare le implementazioni SFTP, abbiamo misurato indipendentemente i limiti approssimativi dell'host. AES-128-GCM ha raggiunto 2.737 MB/s, ChaCha20-Poly1305 1.430 MB/s, le scritture sequenziali su storage 2.687 MB/s, le scritture casuali circa 263.000 IOPS e la rete loopback 1.889 MB/s. I risultati SFTP sostanzialmente al di sotto di questi valori possono quindi essere interpretati come limitati principalmente dal percorso server e protocollo piuttosto che da quei singoli sottosistemi hardware.
Implementazione del client
Il comando sftp standard di OpenSSH non è stato utilizzato come generatore principale di trasferimento perché, in questo ambiente, il suo comportamento single-stream si stabilizzava a circa 90 MB/s. A quel punto, il benchmark avrebbe misurato un limite del client anziché le differenze tra i server.
I test hanno invece utilizzato un client Go personalizzato basato su github.com/pkg/sftp. Esegue letture e scritture concorrenti in modo che il server diventi il lato limitante del trasferimento. La dimensione dei pacchetti SFTP è rimasta a 32 KB, corrispondente ai valori predefiniti normali usati da OpenSSH e pkg/sftp. Abbiamo testato un'impostazione da 256 KB durante lo sviluppo, ma ha causato il fallimento delle connessioni OpenSSH, quindi non l'abbiamo utilizzata.
T1: Throughput single-stream
T1 ha misurato il percorso di trasferimento di base per file di grandi dimensioni. Abbiamo caricato un singolo file da 3 GB e poi scaricato, registrando ciascuna direzione in modo indipendente. Abbiamo ripetuto ogni misurazione tre volte e mantenuto il risultato mediano. Le cache del filesystem venivano svuotate tra le ripetizioni.
Questo test non intendeva stimare il throughput WAN reale. Con client e server sulla stessa macchina, fornisce una visione controllata della rapidità con cui ciascun server può elaborare un flusso SFTP sostenuto quando i limiti della rete e, per la maggior parte delle implementazioni, del disco fisico sono stati rimossi.
T1b: Confronto dei cifrari
T1b ha ripetuto il carico di lavoro di download imponendo dal lato client AES-128-GCM oppure ChaCha20-Poly1305. Ciò ha evidenziato differenze nel supporto dei cifrari e nel modo in cui ciascuna implementazione interagisce con le capacità crittografiche della CPU dell'host.
Abbiamo registrato i cifrari non supportati o i trasferimenti falliti come risultati mancanti. L'host supporta l'accelerazione AES, quindi l'ambiente di test favorisce naturalmente implementazioni AES-GCM efficienti, ma i risultati rimanevano dipendenti dall'implementazione.
T2: Scalabilità dei flussi paralleli
T2 ha misurato come cambiava il throughput aggregato quando lo stesso carico di lavoro veniva suddiviso tra uno, due e quattro flussi simultanei. La quantità totale di dati trasferiti rimaneva fissa a 3 GB; aumentare il numero di flussi modificava quindi la concorrenza.
Il rapporto tra quattro flussi e un flusso è stato usato come indicatore principale di scalabilità. Un risultato vicino a uno suggerisce che connessioni aggiuntive fanno poco per aumentare il throughput, mentre un rapporto maggiore indica che il server può sfruttare capacità di esecuzione aggiuntiva sotto carico parallelo. Poiché il payload totale era fisso, il test enfatizza la concorrenza e l'utilizzo della CPU piuttosto che premiare un carico di lavoro maggiore.
T3: Carico di lavoro con file piccoli
I trasferimenti sequenziali di grandi dimensioni non rappresentano carichi di lavoro dominati da operazioni su filesystem e protocollo. T3 ha quindi caricato 20.000 file da 4 KB ciascuno e misurato i file completati al secondo.
A questa dimensione, la larghezza di banda di trasferimento bulk non è il costo principale. Ogni file richiede una sequenza di operazioni SFTP e lavoro sui metadati del filesystem, rendendo il test sensibile all'overhead di apertura, creazione, chiusura e gestione delle richieste. Integra T1 anziché fungere da ulteriore misura di throughput.
T4: Overhead di connessione e autenticazione
T4 ha eseguito 500 sessioni sequenziali. Ogni iterazione stabiliva una connessione, si autenticava tramite chiave pubblica e si disconnetteva senza eseguire un trasferimento prolungato.
Abbiamo registrato la latenza di connessione come valori p50, p95 e p99, insieme agli accessi completati al secondo. Ciò isola la creazione della sessione SSH/SFTP e rende visibili le differenze architetturali, incluso il costo aggiuntivo di gestione dei processi associato ai server che fanno fork per ogni connessione.
Abbiamo testato l'autenticazione a chiave pubblica. Abbiamo lasciato fuori dal benchmark attuale i percorsi di autenticazione tramite password, keyboard-interactive, certificati, GSSAPI/Kerberos e multi-fattore, quindi T4 non dovrebbe essere generalizzato a questi meccanismi di autenticazione.
T5: Sessioni concorrenti e scalabilità della memoria
T5 ha aumentato progressivamente il numero di sessioni simultanee da 50 verso 500 e ha registrato sia il numero massimo sostenibile di connessioni sia la memoria residente consumata per sessione. Tutti i server giravano con lo stesso limite di memoria di 6 GB.
Questo test è stato particolarmente utile per distinguere le architetture dei server. Le implementazioni derivate da OpenSSH e altre fork-per-connection creano un overhead di processo per sessione considerevole. Al contrario, le implementazioni event-driven, basate su goroutine o threaded possono condividere molto più stato tra le connessioni. Quando un server falliva prima di raggiungere la cima della rampa, il punto di fallimento veniva conservato come parte del risultato, non come estrapolazione di una capacità superiore.
Il tetto di 500 sessioni è un limite di questo ambiente di test. Non è un'affermazione sulla capacità massima dei server che l'hanno completato. Misurare il loro limite superiore effettivo richiederebbe un host più grande e una rampa di connessioni sostanzialmente più elevata.
T6: Efficienza delle risorse
T6 ha misurato l'uso di CPU e memoria mentre un trasferimento continuo era attivo. L'utilizzo della CPU e l'RSS sono stati campionati sull'intero albero dei processi del server ogni 0.5 secondi, anziché monitorare il processo padre.
L'efficienza della CPU è stata normalizzata come percentuale di CPU per Gbps di throughput raggiunto. Ciò fornisce contesto: un basso consumo di CPU è utile se il server sta anche trasferendo dati a una velocità significativa.
T7: Avvio a freddo
T7 ha misurato il tempo trascorso dall'avvio del processo del server fino all'accettazione della prima connessione. Ciò cattura l'overhead di avvio, in gran parte irrilevante per i daemon a lunga esecuzione ma importante per ambienti di test usa e getta, container, servizi di breve durata e flussi di lavoro di distribuzione automatizzati.
La misurazione evidenzia inoltre differenze a runtime che sono per lo più assenti una volta che un processo è caldo, in particolare tra piccoli daemon nativi e applicazioni che devono inizializzare una JVM o un runtime basato su Python prima di accettare connessioni.
Interpretazione dei risultati
I valori mancanti indicano funzionalità non supportate oppure una misurazione che non siamo riusciti a completare; non abbiamo dedotto valori sostitutivi.
L'ambiente loopback è particolarmente importante quando si interpretano T1 e T2. Le classifiche relative e il comportamento di scalabilità sono utili in questo host controllato, ma non trattare i valori assoluti in MB/s come previsioni per una rete reale. Latenza, perdita di pacchetti, prodotto banda-ritardo, storage remoto e comportamento del client possono cambiare sostanzialmente l'esito.
OpenSSH richiede inoltre una precisazione specifica: il suo account del benchmark scriveva su una directory home supportata da disco anziché sul tmpfs usato dalle altre implementazioni. I suoi numeri assoluti T1 e T2 non sono quindi strettamente confrontabili con gli altri server, anche se le misurazioni restano utili per comprenderne il comportamento nella configurazione testata.
Soluzioni di trasferimento file gestito per SFTP
Se desideri più funzionalità amministrative e un uso più semplice, puoi anche scegliere soluzioni di trasferimento file gestito:
JSCAPE
JSCAPE fornisce una piattaforma di trasferimento file gestito con funzionalità di server SFTP, consentendo scambi di file sicuri e crittografati tra reti. Supporta inoltre il protocollo OFTP2 per la trasmissione sicura dei dati nel settore automobilistico e in altri settori.
Scegli JSCAPE come SFTPStonebranch
La funzionalità Secure File Transfer Protocol (SFTP) di Stonebranch fa parte della sua soluzione Managed File Transfer (MFT) e fornisce trasferimenti di dati sicuri, affidabili e automatizzati. Supportando vari ambienti IT, inclusi mainframe, piattaforme cloud e sistemi ibridi, la funzionalità software del server SFTP garantisce crittografia e conformità agli standard di sicurezza del settore, rendendola adatta sia a scambi di file interni sia esterni.
Esplora StonebranchDiplomat MFT di Coviant Software
Diplomat MFT di Coviant Software è una piattaforma di managed file transfer on-premise costruita attorno a SFTP come livello di trasporto sicuro principale, con la crittografia PGP come funzionalità di prima classe. Coviant Diplomat MFT è progettata per organizzazioni in settori regolamentati, come sanità, servizi finanziari, governo e manifatturiero, che necessitano di automazione dei flussi di lavoro no-code, strumenti di conformità integrati e un modello di distribuzione self-hosted stabile.
Esplora Diplomat MFTCerberus FTP Server
Cerberus FTP Server è una soluzione basata su Windows progettata per installazioni on-premise o cloud. Offre integrazione AD/LDAP, SSO, trasferimenti tramite client web e conformità a standard di crittografia come FIPS 140-2. Le funzionalità essenziali includono scansione automatizzata, automazione event-driven e supporto alla conformità HIPAA.
Scegli CerberusGoAnywhere MFT
GoAnywhere MFT fornisce una soluzione SFTP sicura per i trasferimenti di file, ponendo l'accento su crittografia e conformità. Mira a garantire integrità e riservatezza dei dati, con funzionalità per la gestione delle chiavi, l'autenticazione e la registrazione, rivolgendosi alle organizzazioni che danno priorità a scambi di dati sicuri e regolamentati.
Approfondimenti
- Le migliori 10 soluzioni Managed File Transfer (MFT)
- Le migliori 6 soluzioni software AS2: scelte da oltre 400 recensioni
- Axway Managed File Transfer: aspetti chiave da considerare
Aggiungi come fonte preferitaCita questo benchmark
Scegli il formato adatto a dove pubblicherai. Incollare la versione con link nel tuo CMS preserva il backlink.
@misc{dilmegani2026,
author = {Dilmegani, Cem and Ermut, Sıla},
title = {{I 8 migliori software per server SFTP}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/sftp-server-software}},
note = {AIMultiple. Consultato il 20 Agosto 2026}
}Risultati e timestamp di 16 punti dati. Scarica i dati utilizzati in questo articolo come file ZIP contenente 2 file CSV e un README.
Registro delle modifiche
11 aggiornamenti- 2026
Aggiunta una sezione sulla metodologia di benchmark per otto server SFTP.
Sostituita la sezione Files.com con una nuova sezione su Diplomat MFT di Coviant Software.
Aggiunti Stonebranch e Files.com all'elenco delle soluzioni server SFTP.
- 2025
Rimossi Globalscape MFT e MOVEit Managed File Transfer dall'elenco delle soluzioni analizzate.
Rimosso MOVEit Managed File Transfer dall'elenco dei software server SFTP.
Rimosse Figura 1 e Figura dalla sezione Cerberus.
Aggiunto Stonebranch alla sezione "I migliori 8 software server SFTP nel 2026".
- 2024
Aggiunti JSCAPE, Cerberus FTP, MOVEit, GoAnywhere MFT, Files.com, Thru e SolarWinds SFTP/SCP Server all'introduzione.
Aggiunto un link a soluzioni SFTP gratuite nell'introduzione.
Aggiunto Cerberus FTP Server all'elenco delle migliori soluzioni server SFTP.
Aggiunto JSCAPE all'elenco dei software server SFTP.
Il lavoro di Cem presso AIMultiple è stato citato da importanti testate internazionali tra cui Business Insider, Forbes, Morning Brew e Washington Post, da aziende globali come Deloitte e HPE, da ONG come il World Economic Forum e da organizzazioni sovranazionali come la Commissione europea. [1], [2], [3], [4], [5]
Nel corso della sua carriera, Cem ha lavorato come consulente tecnologico, acquirente tecnologico e imprenditore tecnologico. Ha consigliato le aziende sulle loro decisioni tecnologiche presso McKinsey & Company e Altman Solon per più di un decennio. Ha inoltre pubblicato un report McKinsey sulla digitalizzazione.
Ha guidato la strategia tecnologica e gli approvvigionamenti di una società di telecomunicazioni rispondendo direttamente al CEO. Ha inoltre guidato la crescita commerciale dell'azienda deep tech Hypatos, che ha raggiunto ricavi ricorrenti annuali a 7 cifre e una valutazione a 9 cifre partendo da zero in 2 anni. Il lavoro di Cem in Hypatos è stato ripreso da importanti testate tecnologiche come TechCrunch e Business Insider.
Cem interviene regolarmente a conferenze tecnologiche internazionali. Si è laureato come ingegnere informatico presso l'Università di Bogazici e possiede un MBA della Columbia Business School.
In precedenza ha lavorato come reclutatrice in società di project management e consulenza. Sıla ha conseguito un Master of Science in Psicologia Sociale e un Bachelor of Arts in Relazioni Internazionali.
Sii il primo a commentare
Il tuo indirizzo email non verrà pubblicato. Tutti i campi sono obbligatori. I commenti vengono lasciati nella loro lingua originale.